DEV Community: Zayd Mulani

I built a tool that finds shrinkflation in your own grocery orders, and it makes zero network requests

Zayd Mulani — Mon, 12 Oct 2026 11:14:14 +0000

Everyone knows shrinkflation is real. Almost nobody can see their own numbers.

The tools I found fall into three buckets: crowdsourced lists of products that shrank, unit price badges that show today's price per ounce, and one finance tool aimed at analysts. I couldn't find anything that reads your order history and tells you which of the things you keep rebuying got smaller. (I could not search the Chrome Web Store directly, so I can't promise it doesn't exist. If you know one, tell me in the comments.)

So I built Shrinkwatch. Paste your grocery orders into the demo, or use the Chrome extension, and it flags repeat items that shrank and shows what the change cost you per year.

Demo (no install): https://zaydmulani09.github.io/shrinkwatch
Code: https://github.com/zaydmulani09/shrinkwatch

Numbers in this post come from the built-in sample data (8 flagged items, about 10% less food, about $148 a year). They are not real shopper data.

I built it with Claude Code, which is relevant to a few of the stories below.

Step 1: parsing sizes is the whole game

Retailers write sizes like 32 oz, 6 x 12 fl oz, 2 pk, 96 count, 1/2 gallon, 500g. Before you can compare anything you need a parser that turns all of that into a base unit plus a dimension: mass, volume, or count.

The dimension matters because a "count" going from 12 to 10 is shrinkflation, but you never want to compare a mass to a volume. The parser returns something like this (simplified sketch, not the exact repo code):

type Size = { value: number; dimension: "mass" | "volume" | "count" };

// "6 x 12 fl oz" -> { value: 72 * 29.5735, dimension: "volume" }  (in ml)
// "2 pk"         -> { value: 2, dimension: "count" }

Multipacks (6 x 12 fl oz) are where most bugs live, so that is where most of the tests live.

Step 2: deciding two purchases are the same item

If the retailer gives you a product ID (an ASIN, a Walmart item id, an Instacart product id), use it. When it doesn't, you fall back to the normalized name with the size tokens stripped, plus fuzzy token matching.

The trap is variants. Cereal sold in 12 oz and 18 oz boxes at the same time is not shrinkflation, it is two products. So the matcher never merges different sizes that were available at the same time. It only treats a smaller size as a shrink when it replaces the earlier one in the person's own purchase sequence.

Step 3: the detector

For each matched item, sort purchases by date and flag when the size dropped by 2 percent or more. Then compute:

old and new price per unit
the hidden price increase (what you pay per unit now versus before)
a confidence level: high when the product ID matches, medium when the match was fuzzy
a "stealth" label when the sticker price didn't move at all

From purchase frequency it estimates the extra dollars per year, and sums everything into one headline number. Users can dismiss a flag as "not the same product", and that choice persists.

"Nothing leaves your browser" is a claim, so I made it a test

Privacy copy is cheap. I wanted the claim to break the build if it stopped being true.

Three layers:

A test that fails the build if fetch, XMLHttpRequest, sendBeacon, or WebSocket appear anywhere in the extension source.
A strict Content Security Policy on the demo site.
A headless test that deliberately tries a fetch to another host and asserts the CSP blocks it. On the live site I also checked that the only host the page talks to is its own.

The extension also asks for host access only to the retailers it supports, and stores everything in chrome.storage or IndexedDB.

Testing an extension against sites I can't log into

This was the awkward part. I can't put my real accounts into an automated build, so the retailer adapters (Instacart, Walmart, Amazon, Target, Kroger) were developed against realistic fixture pages I wrote myself.

To keep that honest:

The adapters don't rely on brittle class names. They use generic heuristics (price patterns, product links, title text) with small per-site hints.
A "selector health" view shows exactly what the extension captured on a page, so breakage is visible instead of silent.
Pasting order text works as a fallback and uses the same core code.
The README says plainly that adapters are best effort until verified on live pages. I'm saying it here too.

For the extension itself I used Playwright to load the built extension in headless Chromium in its own profile and click through capture, dismiss, paste import, and the popup. One of my first bugs was my own: a "block all requests" route handler was also aborting the extension's own files. Routing only http and https fixed it.

The Lighthouse rabbit hole

The demo is a static page, so I figured performance would be easy. Mobile scored 80 at first. Here is what actually moved it:

Prerender the hero. The big headline number was rendered by JavaScript, which made it a late largest paint. It is now in the HTML at build time.
Memoize name tokenization. Profiling showed the name tokenizer dominating. The same product names repeat hundreds of times in the sample orders (723 in my profile), so caching it removed a lot of work with no logic change.
Stop using Intl for money. The first call to Intl.NumberFormat was slow enough to show up as a long task on a throttled phone. Plain formatting did the job.
Load the script with async, not defer. With defer, the script ran inside the same task as the first layout, so the profiler counted the layout as blocking time.
Fonts. Cumulative layout shift came from web fonts swapping in. font-display: optional fixed the shift but meant some first-time visitors never saw the real fonts, so I ended on swap with local fallback fonts sized to match the web font's width using size-adjust. I also subset the hero fonts, cutting font weight from roughly 280KB to roughly 97KB.
content-visibility: auto on below-the-fold sections, and rendering the long receipt only when it nears the viewport.

On the live site, mobile ended at 97 performance and 98 accessibility, desktop at 100, with accessibility and best practices at 100. One lesson: local Lighthouse numbers on my machine were noisy enough that I stopped trusting them and measured on the deployed page instead.

Not looking like every other AI-built site

My first version worked, and looked exactly like what it was. So I had the design redone against a written brief: warm paper background, ink-black text, one accent color reserved for money and size lost, no gradients, and a pack drawing that shows the old size next to the new one. Fonts are self-hosted (Newsreader, Libre Franklin, IBM Plex Mono, all OFL), which also keeps the zero-third-party-requests promise true.

What I'd like from you

Try the demo with your own orders and tell me what it misses. If you use the extension, the selector health view output is the most useful thing you can send me.
If an adapter breaks on your account, open an issue. Adding a retailer is documented in the README.
If you know a tool that already does this, I'd genuinely like to see it.

What's the worst shrinkflation you've caught?

I wanted Jepsen's Elle in CI without a JVM, so I wrote adya

Zayd Mulani — Tue, 06 Oct 2026 22:53:50 +0000

Your database documentation says REPEATABLE READ. Your code assumes it. Have you ever checked?

I spent the last stretch building adya, a black-box checker for transactional isolation. You give it a log of transactions a database ran, and it tells you which isolation guarantees held. For each one that didn't, it prints the transactions involved and the chain of reads and writes that proves the violation.

It's an independent Rust implementation of the approach from Elle (Kingsbury and Alvaro, VLDB 2020), the checker behind Jepsen's database analyses. If you know Elle, adya reads the same history formats and takes the same flags. If you don't, keep reading.

The problem with "it passed the tests"

Isolation bugs don't show up in unit tests. They need two or more transactions to interleave in one particular way, and when they happen nothing crashes. You just get a balance that's off, or two people booked into the same seat.

The classic example is write skew. Two doctors are on call, and the rule says at least one must stay on call. Each doctor's transaction checks "is the other one still on call?", sees yes, and takes themselves off. Both commit. Now nobody is on call.

Snapshot isolation allows this. Postgres's REPEATABLE READ is snapshot isolation, so it allows this. If you thought REPEATABLE READ meant "safe enough", the bug ships.

Elle's insight was that you can catch this from the outside. Record what every client asked for and what it got back, infer the dependencies between transactions, and look for cycles that a given isolation level forbids. Atul Adya's 1999 thesis catalogued those cycles (G0, G1c, G-single, G2 and so on), which is where the name comes from.

Why another implementation

Elle is excellent. It's also a Clojure library on the JVM. People who want it outside a Jepsen test end up shelling out to elle-cli from a Go or Python harness. I found two open-source projects doing exactly that in CI (barn, bytecaskdb), and the bytecaskdb PR lists what went wrong: a blocked Clojars mirror, a crash when graphviz was missing, log lines corrupting the JSON output.

On my Windows machine, elle-cli 0.1.11 hung with no output on every anomalous history I gave it. On Linux it worked, but in my CI comparison it needed more than five minutes on five of forty random 300-transaction histories, and ran out of a 6 GB heap on one more. adya checked all forty in 0.2 seconds.

Elle also leaves the workload to you. You have to write the client that generates transactions, runs them against your database and records the history. That's the part most people never get to.

So adya ships both halves in one binary:

cargo install adya

# Run a workload against Postgres at REPEATABLE READ,
# then check the history against serializability.
adya run postgres --url postgres://localhost/test -i repeatable-read -c serializable

What it looks like

You don't need a database to try it. adya has a built-in simulated database that implements isolation levels the textbook way:

$ adya run sim -i snapshot-isolation -c serializable -n 300 -p 4 --seed 1
history.jsonl   false

G2-item #0
  Let:
    T234 = {"index":234,"process":1,"type":"ok","value":[["r",10,[4]],["append",3,6],["r",3,[4,5,6]]]}
    T237 = {"index":237,"process":3,"type":"ok","value":[["append",9,13],["append",10,5],["r",3,[4,5]],["r",10,[4,5]]]}
  Then:
    - T234 < T237, because T234 did not observe T237's append of 5 to 10.
    - However, T237 < T234, because T237 did not observe T234's append of 6 to 3: a contradiction!

That's the doctors problem with list keys. T234 read key 10 before T237 appended to it, so T234 has to come first. T237 read key 3 before T234 appended to it, so T237 has to come first. Both can't be true, so no serial order exists. Snapshot isolation allows that cycle. Serializability doesn't.

How it works

The trick that makes this tractable is the workload. adya's default, borrowed from Elle, is list-append: every key holds a list, transactions append unique numbers to lists and read whole lists back. Each read then tells you the order of every append before it. If one client read [1, 2] and another read [1, 2, 5], you know 5 came after 2, without asking the database anything.

From those orders adya builds a dependency graph over transactions, using Adya's three edge types:

ww: T2 appended right after T1's append to the same key.
wr: T2 read a list ending in T1's append.
rw: T1 read a list that T2 later appended to, so T1 didn't see T2's write.

If you're checking a model with real-time guarantees (strict serializability), it adds edges for "T1 finished before T2 started", using a transitive reduction so the graph stays roughly linear in the history.

Then it looks for cycles, one strongly connected component at a time. Each anomaly class is a cycle with constraints. G-single has exactly one rw edge. G2-item has at least two, with two of them adjacent. G1c has no rw edges and at least one wr. Instead of enumerating cycles and classifying them afterwards, adya runs a breadth-first search over pairs of (transaction, path state). The path state is seven bits: how many rw edges so far (0, 1, or 2+), whether the last edge was rw, whether the first one was, whether two were adjacent, whether it has seen a wr, and whether it has used a real-time edge. One BFS then returns the shortest cycle of exactly the shape you asked for.

Before searching, it runs cheaper existence checks. For each model it asks whether the subgraph that model forbids cycles in has a nontrivial SCC at all. If the ww/wr-plus-one-rw subgraph is acyclic, snapshot isolation holds as far as cycles go, and adya skips every search that could only find SI violations. It also searches the most severe anomalies first and skips anything they imply. A 100,000-transaction history (30 MB of JSON) checks in about 1.6 seconds on my laptop.

Is it right?

A checker that's wrong is worse than none, so this took most of the work.

Elle's own expected results. elle-cli's test suite ships 56 list-append and rw-register histories along with the JSON verdicts Elle produced for them. adya matches all 56: same verdict, same anomaly types, and the same weakest models ruled out. Getting there taught me two Elle details I would never have guessed. It labels an edge that carries several relations by a fixed priority (ww before wr before rw before real-time), but tests whether a cycle exists using any relation the edge carries. And it counts a composed edge that loops back to the same transaction as a cycle.
Elle itself, live. On every push, CI generates random histories with adya's simulator and checks each with both tools. In the first full run Elle finished 34 of 40, and adya agreed on all 34.
Databases with known answers. The simulator implements serializable, snapshot isolation, read committed (with write locks), read uncommitted, and a deliberately broken "snapshot" that writes back stale state. Tests assert that correct runs produce zero anomalies at their own level and the expected ones above it. That test caught a bug in my simulator, not in the checker: my first read committed took no write locks, which is weaker than any real database.

What Postgres and MySQL did

CI runs 4,000 transactions from 10 clients over 6 hot keys against Postgres 17 and MySQL 8.4, at each isolation level, and checks every history against a ladder of models. List-append results:

database, level	serializable	snapshot isolation	read committed
Postgres `READ COMMITTED`	G-single, G2-item, internal, lost update	G-single, internal, lost update	valid
Postgres `REPEATABLE READ`	G2-item	valid	valid
Postgres `SERIALIZABLE`	valid	valid	valid
MySQL `REPEATABLE READ`	G-single, G2-item, internal, lost update	G-single, internal, lost update	valid
MySQL `SERIALIZABLE`	valid	valid	valid

Postgres did what its docs say. REPEATABLE READ is snapshot isolation, write skew included, and SERIALIZABLE came out strict serializable. I also restarted Postgres every few seconds during a 6,000-transaction SERIALIZABLE run (--fault "docker restart -t 0 pg"). Nine restarts, 2,957 commits, 3,043 failures, and the history still checked clean.

MySQL's REPEATABLE READ is weaker than its name. It lets a transaction lose another's update and see part of another transaction's writes, so it isn't snapshot isolation. Jepsen reported the same thing about MySQL 8.0.34 in 2023. adya reproduces it from a cold start in a few seconds.

Testing your own database

The built-in drivers cover SQLite, Postgres and MySQL. For anything else there's adya run exec: adya starts your client once per process, writes one JSON line per transaction to its stdin, and reads back one line saying what happened.

{"value":[["append",3,7],["r",4,null]]}
{"type":"ok","value":[["append",3,7],["r",4,[1,7]]]}

The repo has a 59-line Python client for SQLite as a template. Swap the SQL and you're testing your own database.

Limits

adya covers list-append and read-write register workloads. It doesn't do predicate reads, or Elle's bank, set and counter checkers. It prints text proofs instead of Graphviz plots. A clean result means it found no anomaly in that history. It doesn't prove your database is correct, so run it longer, with fewer keys for more contention, and with faults.

If you run it against something interesting, I'd like to hear what it found. Issues and PRs are open.

GitHub: https://github.com/zaydmulani09/adya
crates.io: https://crates.io/crates/adya

I built a tool that finds the minimal cause of a browser bug by replaying it

Zayd Mulani — Wed, 30 Sep 2026 04:07:01 +0000

Some bugs only happen with one combination of API data, timing and local state. The failing run and a working run differ in dozens of ways, and figuring out which difference matters usually means commenting things out until something changes.

Causality Cage automates that. You give it a failing session and a passing session. It replays the flow in Chromium with the differences switched on and off (API response fields, latency, response order, localStorage, cookies, environment), uses hierarchical delta debugging to shrink the set, then re-checks the answer by removing each piece and replaying.

What it looks like

The report is a single offline HTML file with a causal graph. Click a factor to neutralize it and the failure node flips from red to green.

A real bug

I ran it on a closed issue in the RealWorld React app: gothinkster/react-redux-realworld-example-app#187. The app crashes with "Cannot read property 'tags' of undefined", and the reporter traced it to a stale token in localStorage. The original API host is dead, so I pointed the app at a public RealWorld API.

On the issue's commit, cage returned the full chain in 19 experiments (25.1 s): the stale token AND the API rejecting the two requests it triggers.

My first version said "the token" alone. Its minimal configuration crashed with a different error, and it counted any crash as the bug. So it now fingerprints the original failure and only counts runs that fail the same way. --loose-oracle restores the old behavior, which names the token alone in 10 experiments. The same run also exposed a redaction leak in my own report, which is fixed. The raw output is in launch/real-world.md.

What it does not claim

A result is necessary and sufficient only within the factors it models, under your flow and your oracle, at the measured repeat rates. It is 1-minimal, not guaranteed globally smallest. It does not model server-side state, WebSockets, IndexedDB or static assets. When the cause is out there, it says "unexplained" instead of naming something. Every report prints that scope box.

On a benchmark of planted bugs in my own demo app it matched ground truth on 10 of 10 rows, with caveats:

The OR row (two causes that crash with different messages) needs --loose-oracle. In strict mode it finds only one.
The flaky-oracle row failed after I added failure matching. It passes because of a rule I added afterwards: runs that crash before reaching the target failure are excluded from the fail rate.
The latency race flip point was 808 ms against an expected 600 to 900 ms band.

The app is mine, so treat that as a self-check, not evidence it works on yours.

Try it

npm install -g causality-cage
npx playwright install chromium
cage doctor

Everything runs locally. There are no LLM calls (the verdict text is a template), and it can export a standalone Playwright test that fails until the bug is fixed.

Repo: https://github.com/zaydmulani09/causality-cage (MIT)

I'd most like to hear about bugs where it gives a wrong or useless answer.

How I stream row changes out of SQLite without touching the app (reading the WAL)

Zayd Mulani — Mon, 28 Sep 2026 18:16:54 +0000

SQ
Lite has no way to tell another process "row 42 in users just changed." I wanted that,
so I built tailite: it follows a live SQLite
database from outside and emits every committed insert, update and delete with before and
after values. The writing app doesn't change.

The options that didn't work

sqlite3_update_hook and the preupdate hook only run inside the process doing the write.
The session extension has to be turned on by the writer.
Trigger-based CDC adds triggers and a log table, which is fine for your own app and not an option for a database some other app owns.
Litestream and LiteFS replicate pages. That's great for backups, but they can't tell you which row changed.

So: read the write-ahead log myself.

Step 1: which transactions are committed?

A WAL is a 32-byte header plus frames (24-byte header + one page image). Each frame's
checksum chains from the previous one, and a frame with a non-zero "db size" field ends
a transaction. I accept frames by the same rule SQLite's recovery uses: salts match the
header, the checksum chain is unbroken, and the run ends in a commit frame. Anything
still being written or rolled back just fails the chain.

Step 2: pages → rows

A transaction is a bag of page images. To get rows you need to know which table each page
belongs to, and SQLite pages don't point back to their parent. tailite builds a
page → table and page → parent map once, then updates it per transaction by walking only
the paths from changed pages up to their roots.

The surprise was deletes. When SQLite frees a page it skips writing it
(sqlite3PagerDontWrite), so after a big DELETE the freed leaves aren't in the WAL at
all. Their old images still hold the deleted rows, though. So the tracker looks for
orphans: pages that were on a changed path and didn't show up again when re-walking the
new tree. It reads their old images.

My first version assumed "parent page unchanged → page still in the tree." DELETE FROM t
broke that: the table's root got rewritten, and pages below unchanged-but-freed parents
went stale. The randomized tests caught it. The index self-check (rebuild from scratch
after every commit, compare) pointed straight at the drifted pages.

Step 3: two gotchas in the record format

Same-size blob updates. SQLite overwrites overflow pages in place, so the leaf page stays byte-for-byte identical and only an overflow page changes. I keep an overflow page → row index for exactly this case.
REAL affinity. Store 140.0 in a REAL column and SQLite writes the integer 140 to disk, then converts it back when you read. The decoder has to do the same.

Step 4: checkpoints will ruin your day

This is the part that matters. A checkpoint copies WAL frames into the main database
file, and once everything is copied the next writer resets the WAL. If that happens
before you've read a transaction, you lose its frames, or you lose the old version of a
page you needed for the "before" image.

SQLite already protects readers from this: it never checkpoints past the snapshot of an
open read transaction. So tailite holds one (I call it the pin) at a point it has
already processed. Each poll it opens a new pin, reads everything in the log, then drops
the old pin. At every moment some pin sits at or behind what's been processed. Litestream
uses the same trick.

To make sure this wasn't just theory, I wrote a test where a writer thread commits and
runs PASSIVE/RESTART/TRUNCATE checkpoints while tailite polls. I disabled the pin and ran
it again: it failed every run (frames vanishing mid-read, wrong before-images, duplicate
inserts). With the pin it passes on Linux, macOS and Windows.

Testing against SQLite itself

The main test is differential. Random workloads (inserts, range deletes, DELETE FROM,
INSERT OR REPLACE, VACUUM, auto_vacuum, 512-byte pages, WITHOUT ROWID tables, DDL)
run through real SQLite. Every event gets replayed into a mirror, and after every poll the
mirror must equal SELECT * of every table. Updates and deletes also have to carry the
exact previous row.

Using it

cargo install tailite
tailite watch app.db --json      # JSON Lines, one object per row
tailite watch app.db --snapshot  # existing rows first, then the stream
tailite diff old.db new.db       # row diff of two files

Or as a library: Tail::open, poll, snapshot.

Limits (being honest)

WAL mode only for watch. You get the net effect per transaction, not statement order.
There's no resume across restarts yet. Attaching reads the whole database once.

Repo and architecture notes: https://github.com/zaydmulani09/tailite

I built a tool that pulls the power cord on your program (thousands of times)

Zayd Mulani — Fri, 25 Sep 2026 02:06:50 +0000

write() returning doesn't mean your data is on disk. Even fsync() doesn't cover everything. A file system may persist writes out of order, tear them at block boundaries, save a file's new size without its data, and drop a new directory entry unless you fsync the directory. Code that passes every test can still lose data, or corrupt its state, when the power fails at the wrong moment.

These bugs are common in serious software. Pillai et al. (OSDI '14) found 60 of them across 11 applications, including databases and version-control systems. But the tool from that paper, ALICE, is unmaintained. So I built unsynced.

What it does

Record what a program does to a directory: strace for any program on Linux, or a Recorder API for Rust code on any OS.
Compile each operation into the pieces a file system can persist independently (directory entries, 4 KiB write chunks, size changes), each tagged with the fsync that makes it durable.
Enumerate every on-disk state a crash could leave under a persistence model (the weakest POSIX allows, or ext4's default).
Check each unique state with your checker. It gets the directory plus what the program had acknowledged (printed) before the crash.
Explain. Each failure is minimized to the lost operations that cause it, classified, and turned into a fix.

unsynced run --init seed/ \
--check 'c=$(cat {dir}/cfg); [ "$c" = v2 ] || { ! grep -q saved {marks} && [ "$c" = v1 ]; }' \
-- sh -c 'printf v2 > {dir}/tmp && mv {dir}/tmp {dir}/cfg && echo saved'

[1] reordering (7 failing states)
lost #1 write tmp [0..2)
but persisted #2 rename tmp -> cfg
fix fsync tmp before rename tmp -> cfg (op #2); the rename reached disk before the data it points to

[2] unsynced (1 failing states)
lost #2 rename tmp -> cfg
fix fsync the directory . after rename tmp -> cfg and before acknowledging ("saved")

The SQLite test

To see whether the model was realistic, I ran SQLite under every journal mode and synchronous level, with a checker demanding integrity plus every acknowledged commit. unsynced knows nothing about SQLite:

mode	unsynced	SQLite docs
DELETE + FULL	commit lost: journal unlink not dir-fsynced	EXTRA exists to sync the dir after that unlink
DELETE + EXTRA	clean	ACID
WAL + NORMAL	commit lost: WAL not fsynced before commit returns	"might roll back following a power loss"
WAL + FULL	clean	ACID
OFF	`database disk image is malformed`	"might become corrupted"

Every row matches the docs, and CI re-runs this on every push.

Crashing the recovery

Recovery code writes to disk too. With --recover, each repair is traced and crashed at every step, then run again. The example in the repo is a log whose torn-tail repair rewrites the file: correct in every normal test, but it loses acknowledged data if the power dies mid-repair. The same repair done with set_len survives.

Try it

cargo install unsynced

Repo, model spec and limitations: https://github.com/zaydmulani09/unsynced

Semantic code search without a vector index

Zayd Mulani — Sat, 19 Sep 2026 15:18:10 +0000

Every "AI code search" tool released this year does the same thing under the hood: chunk your repo, embed every chunk, stuff the vectors into an index, and keep that index in sync every time you commit. GitLab Duo does it. Sourcegraph does it. JetBrains shipped a whole RAG pipeline for it. It works, but it means you're maintaining a second copy of your codebase that can drift out of sync with the first one, and on a repo that changes fast, "rebuild the index" becomes its own chore.

I wanted semantic search that didn't need that. So I built jevgrep, and it skips the index entirely.

The actual mechanism

jevgrep does two passes, and only one of them touches a model.

Pass one is plain old ripgrep, doing a fast keyword sweep over the repo to pull maybe 30 to 50 candidate lines. This part is dumb on purpose. It doesn't need to understand your query, it just needs to narrow a whole repo down to a short list fast, which is the one thing keyword search is genuinely good at.

Pass two hands that shortlist to Jev, TypeSafe's decision model, in a single batched call. Jev isn't a chat model, it's what they call a System One model: it doesn't generate text token by token, it reads probabilities over a fixed set of options in one forward pass. So instead of asking an LLM to write out a ranked list (slow, and it'll happily hallucinate a line number that doesn't exist), you hand it the query plus the candidates as typed choice options, and it hands back a probability distribution over which candidate actually answers the query. No decoding loop, no JSON the model might get wrong, just a ranking.

That's the whole trick. Keyword search does recall, Jev does relevance, and there's nothing to rebuild when you push a commit because there's no index in the first place. The tradeoff is honest: you're bounded by whatever ripgrep's keyword pass surfaces in the first place, and Jev's context window caps you around 50 candidates per call. This isn't a replacement for a real embedding index on a codebase where the right answer literally doesn't share a single word with the query. It's a much cheaper tool for the far more common case, where the right answer is a few keyword-adjacent hops away from what you typed.

Does it actually work

I ran it against Flask's real source, not a toy repo, because Flask's config.py has genuine config-parsing logic (from_pyfile, from_prefixed_env, from_envvar) that isn't reducible to a single obvious keyword.

Query: "where do we load environment variables"

flask/cli.py:701    27%  Load "dotenv" files to set environment variables...
flask/config.py:129 12%  Load any environment variables that start with FLASK_

Plain rg "load environment variables" returns 2 hits, both docstrings, missing the actual mechanism. rg "os.environ" returns 14 hits with no ranking, meaning you already need to know the exact symbol and then eyeball all 14 yourself.

Query: "where do we parse the config file"

flask/config.py:209  68%  exec(compile(config_file.read(), filename, "exec")...)
flask/config.py:270   5%  app.config.from_file("config.json", load=json.load)
flask/config.py:273   3%  app.config.from_file("config.toml", load=tomllib.load...)

That top hit is the line that actually reads and executes a Python config file. The words "parse" and "config file" don't appear on it together anywhere. rg "parse config file" returns zero results, because those words never co-occur in Flask's source at all. That's the actual gap between text matching and understanding intent, on a real production codebase, not a cherry-picked demo repo.

Worth being straight about the failure mode too: run jevgrep on its own repo (which has no real config-file parser) and it correctly surfaces argument-parsing code instead, because that's the closest real match that exists. It doesn't invent a config parser that isn't there. For a tool whose whole pitch is trustworthy ranking, that matters more than a good demo would.

Cost and speed

Jev's list price is $0.042 per million input tokens with output free, and each jevgrep query is maybe 30 to 60 tokens of state. End to end it ran at 945ms in my test, which was a cold call on Windows without ripgrep on PATH, falling back to a pure Python scan for pass one. With ripgrep actually resolving, the shortlist pass drops to single-digit milliseconds and the Jev call itself is typically 70 to 500ms, so the realistic number is well under a second, consistently.

Try it

pip install git+https://github.com/zaydmulani09/jevgrep

jevgrep "where do we parse the config file"

You'll need a free OpenRouter API key to call Jev (new accounts get $1 in credit, which at Jev's pricing is on the order of tens of thousands of queries). Full setup is in the README.

Repo: github.com/zaydmulani09/jevgrep, MIT licensed.

If you're building something in this space, I'd genuinely like to hear what tradeoffs you hit, especially anywhere the shortlist-then-rank approach falls over on a codebase bigger than what I've tested against so far.

My "secure" sandbox detected an attack and reported success anyway. Here's the marshaling bug that caused it.

Zayd Mulani — Mon, 24 Aug 2026 21:36:24 +0000

I built a tool (mri) that runs untrusted code snippets inside a sandbox, checked against an execution allowlist derived from a dependency graph. Before I trusted it for anything, I wrote a demo: three attacks, all blocked. Then I stopped testing.

That was a mistake, and I only found out because I went back and wrote a second benchmark whose entire purpose was to disprove the first one — 19 cases of ordinary code that should just run, and 14 attack cases that weren't in my original three.

The legitimate-code suite failed first, and badly. 5 of 19 normal patterns got blocked, including a plain function declaration with parameters and a try/catch block. The static scanner registered local bindings for arrow-function params but never for function_declaration params or catch-clause bindings — so those names looked like unresolved external references to the scanner, and unresolved means blocked, by design. A tool that blocks ordinary code isn't safer than one that doesn't. It's the kind of tool that gets a comment added to disable it.

The attack suite found something worse than a missed attack. One case: a getter that doesn't touch process.env until the return value gets read on the way out of the sandbox. That access triggered the runtime's real violation check — the detection fired correctly. Then the code responsible for serializing that return value back to the host caught the resulting error, converted it to a string, and handed back a clean "executed" result. Nothing in the breach log. The check worked and the report lied about it. I'd rather have a tool that misses something and says so than one that catches something and hides it.

Also found: the sandbox wasn't a real boundary in the first place. I was using node:vm, and console.log.constructor.constructor (or the same trick through any host-provided reference) reaches the host process's actual Function constructor. This is documented — Node's own docs say vm doesn't provide security isolation — but "documented" and "tested against my own code" are different things, and I hadn't done the second one.

Fixed the sandbox by moving to isolated-vm, a real separate V8 isolate rather than a shared-realm context. Fixed the marshaling bug by making sure any violation, wherever it's triggered from, produces a blocked verdict before a return value ever gets serialized. Re-ran the full 33-case benchmark after both fixes: zero regressions, both cases now correctly blocked.

Still true after the fixes: no OS-level sandboxing underneath the isolate, no taint tracking between two resources that are each individually granted, and it only evaluates one snippet at a time — no whole-program analysis.

Repo, including the benchmark harness and raw per-case results: https://github.com/zaydmulani09/mri

I built a static + runtime security scanner for MCP servers (Rust)

Zayd Mulani — Wed, 19 Aug 2026 04:05:33 +0000

I built a static + runtime security scanner for MCP servers (Rust)

TL;DR: MCP (Model Context Protocol) has had 40+ CVEs disclosed just this year, and there wasn't a purpose-built scanner for it, so I built one. sentrymcp does static analysis (path traversal, injection, tool poisoning, missing auth) plus a runtime proxy mode that catches "rug pulls" — servers that silently change a tool's description after you've already approved it. Rust, MIT, Docker one-liner. Repo: https://github.com/zaydmulani09/sentrymcp

Why this exists

I've been building MCP tooling for a while (a reverse proxy, some agent infra), and at some point I went looking for something to check my own servers for basic security mistakes before shipping them. There wasn't really anything.

That surprised me, because the CVE numbers aren't small. Endor Labs analyzed over 2,600 real MCP implementations and found 82% use file operations prone to path traversal, 67% use APIs related to code injection, and 34% use APIs susceptible to command injection. Separately, researchers have put the no-auth rate at around 38-40% of scanned servers — meaning close to 2 in 5 MCP servers in the wild have no authentication at all.

The vulnerability classes aren't exotic either. Anthropic's own reference implementation, mcp-server-git, shipped a path traversal bug where a repo_path argument was never validated against a configured boundary — the exact "developer forgot one check" pattern that shows up constantly in these audits.

So: static analysis for the code-level stuff, and since MCP has an attack class that literally can't exist in source code (a server that changes its tool description mid-session, after the user already approved the original), a runtime mode to catch that too.

What it catches

Category	What it detects	Example
Code vulnerabilities	Path traversal, command/shell injection, unsafe eval/code-injection sinks	Unvalidated file path args, string-interpolated `exec()` calls
Tool poisoning	Hidden instructions embedded in tool descriptions, unicode/homoglyph obfuscation	"ignore previous instructions" phrasing, Cyrillic lookalike characters hiding in description text
Auth & permissions	Missing auth on HTTP/SSE transports, hardcoded credentials, credentials leaked via logging	`api_key = "sk-..."` as a literal, unauthenticated SSE endpoints
Runtime (proxy mode)	Tool description changes after initial approval ("rug pulls"), unexpected outbound connections	A tool's description silently changes between the first and second `tools/list` call in a session

The tool-poisoning detection is the one I'm most interested in feedback on. MCP tool descriptions get read directly into the model's context as trusted content, so an attacker who controls a description can hide instructions the LLM will act on while the user only sees a benign-looking label. sentrymcp checks for imperative hidden-instruction phrasing, zero-width/bidi-control unicode, and homoglyph mixing (Latin text with Cyrillic or Greek lookalike characters slipped in).

Usage

Static scan:

mcpaudit scan ./some-mcp-server

Output is ranked by severity with a CWE or OWASP MCP Top 10 reference and a one-line remediation for each finding, split into three sections — code vulnerabilities, tool poisoning, and auth/permissions.

Runtime proxy mode, sitting between your MCP client and the real server:

sentrymcp proxy -- <your-server-command>

This baselines every tool definition it sees on session start and diffs every later tools/list response against it. Any change gets flagged and logged as a JSON event, with a human-readable summary at session end.

Docker, no local Rust toolchain needed:

docker build -t sentrymcp .
docker run --rm -v $(pwd):/scan sentrymcp scan /scan

How it's built

Rust workspace, four crates: a core scan engine, a rules crate that loads detection patterns from TOML files (so adding a new check doesn't require recompiling), a CLI, and the proxy. Rule-driven design was a deliberate choice — path traversal, injection, and tool-poisoning heuristics are all just declarative pattern definitions with a severity, a reference (CWE or OWASP MCP Top 10 id), and remediation text, which makes the ruleset easy to extend as new attack patterns show up.

Limitations (being upfront about these)

Detection is regex/pattern-based, not AST or taint-tracking. It'll miss vulnerabilities that flow through an intermediate variable before hitting a sink — this is a known, documented gap, and proper taint analysis is the natural next step.
Description extraction for tool-poisoning checks is targeted, not a full parser — it handles the common registration patterns in Python/TS/JS but isn't exhaustive.
The runtime proxy's network-connection monitoring is currently Windows-only and best-effort (polls netstat, not a real sandbox).
Heuristic findings (like "no visible auth pattern anywhere in the file") are marked with a confidence flag separate from severity, since absence-of-pattern checks are inherently noisier than presence-based ones.

Try it / feedback wanted

Repo's here: https://github.com/zaydmulani09/sentrymcp — MIT licensed, contributions welcome. If you run MCP servers, I'd genuinely appreciate people trying the scanner against their own and telling me what it misses or false-positives on. The corpus of test cases is still small and real-world feedback is the fastest way to make the ruleset actually useful instead of just theoretically correct.

I built a local LLM that runs entirely in your browser. No install, no GPU, no server

Zayd Mulani — Mon, 27 Jul 2026 18:34:05 +0000

A few months ago I got obsessed with a question: can you run a real LLM entirely inside a browser tab, with zero backend, zero GPU, and zero install?

The answer is yes. Here's what I built.

ghost is a single HTML file that downloads a quantized language model into your browser's cache on first visit, then runs inference locally in WebAssembly forever after. Fully offline after that first download. No API key. No npm. No build step. Open the file, pick a model, chat.

How it works

The inference engine is wllama — a WebAssembly binding for llama.cpp. It runs GGUF quantized models directly in the browser using WASM SIMD. I pin it to a specific version so the JS and WASM files always match (learned this the hard way after a fun debugging session involving mismatched memory imports).

Models are downloaded from HuggingFace on first load and cached via the browser's Cache API. On every subsequent visit they load instantly from cache, no network needed.

Features

Three models: Qwen2.5 1.5B (smart), Qwen2 0.5B (fast), TinyLlama (lightweight)
Markdown rendering from scratch — no library, just regex transforms
RAG: drag a .txt or .pdf onto the chat window. It chunks the text, embeds each chunk using wllama's embedding API, stores vectors in memory, and retrieves the top-3 relevant chunks on each message. Fully local, fully offline
Voice input via the Web Speech API — mic button auto-sends on silence
Multi-turn conversation memory capped at 10 turns
PWA installable — works on mobile home screen too

The hard parts

Getting wllama to load from a cached model was genuinely tricky. Blob URLs created in the main thread aren't accessible from wllama's internal Web Worker. IndexedDB chunk reconstruction hit a 2GB ArrayBuffer limit on Windows Chrome. The final solution was using wllama's built-in loadModelFromHF with useCache: true which handles everything internally.

The embeddings API requires toggling a flag (embeddings: true) that conflicts with normal chat completion — so I toggle it on before each embedding call and back off in a finally block.

Try it

Live: https://zaydmulani09.github.io/ghost/ghost.html
GitHub: https://github.com/zaydmulani09/ghost

Speed on CPU is ~3-8 tokens/sec depending on model. Not fast, but it works, and every token stays on your machine.

I built a local-first coverage-guided fuzzer in Rust with LLM seed bootstrap

Zayd Mulani — Tue, 14 Jul 2026 13:27:34 +0000

I built a local-first coverage-guided fuzzer in Rust with LLM seed bootstrap

rust #opensource #security #fuzzing

The problem that kept bothering me: I wanted to fuzz a custom binary protocol parser. Not something with a public corpus of real traffic. Just a service my team built that speaks a length-prefixed binary format over TCP.

AFL++ requires a C harness. cargo-fuzz wraps libFuzzer but you still need to write the harness and you're starting from random bytes. Neither tool helps you when the first thing the parser does is check a 4-byte magic header and exit if it doesn't match. You spend hours getting past that check before you find anything real.

So I built Phaedra.

The LLM seeding idea

The core insight is that you don't need random bytes to start. You need bytes that look plausible. If you describe what your target parses in plain English, a language model can generate a structured initial corpus.

phaedra fuzz \
  --target ./my_parser \
  --description "TLV binary protocol with PHDR magic header, u8 type, u16be length, payload bytes"

Phaedra sends that description to a local Ollama instance and gets back hex-encoded seed inputs. No API key, no data leaving your machine. OpenAI and Anthropic work as drop-in backends if you want them.

The seed generation prompt asks for variety: valid inputs, boundary values, truncated records, inputs where the length field exceeds the payload. The parser gets past the magic check immediately because the seeds include valid magic bytes. Campaign starts finding new coverage on the first execution instead of the hundredth.

Coverage via SanCov edge bitmaps

Once you have seeds, you need coverage feedback. I chose SanCov edge bitmaps over shared memory rather than LLVM .profraw files for one reason: speed. Reading a profraw file after each execution means a file write, a file read, and a parse. Shared memory is a single shmat call and a memcpy.

The setup: Phaedra allocates a 65536-slot edge bitmap in POSIX shared memory, passes the segment ID to the target via __PHAEDRA_SHM_ID, and the target's SanCov runtime shim writes edge hit counts directly into that segment on every execution. After the process exits, Phaedra reads the bitmap, XORs against the global "seen" bitmap, and if new edges fired, the input goes into the corpus.

The shim is a small C file that gets compiled into the target:

void __sanitizer_cov_trace_pc_guard(uint32_t *guard) {
    if (!*guard || !phaedra_map) return;
    phaedra_map[(*guard - 1) % PHAEDRA_MAP_SIZE]++;
}

Schema-aware mutation

Random byte mutation gets past the magic check once you have good seeds. But it still struggles with structured fields. If your protocol has a u16be length prefix followed by exactly that many payload bytes, random mutation almost never produces a valid record because it corrupts the length without adjusting the payload.

The schema DSL solves this. You describe your protocol in TOML:

name = "my_protocol"

[[fields]]
name = "magic"
type = "magic"
length = 4
value = "50484452"
mutable = false

[[fields]]
name = "length"
type = "u16_be"

[[fields]]
name = "payload"
type = "lp_bytes16_be"

30% of mutations operate at the field level: corrupting the length prefix specifically, setting it to 0, to max value, or to a value larger than the actual payload. The other 70% are still raw byte mutations. The split keeps the campaign from getting stuck in schema-valid inputs only.

If you have a corpus but no schema, phaedra infer analyzes the samples with six heuristics and writes a starting schema:

phaedra infer --corpus-db ./phaedra-corpus/corpus.db --name my_proto

Crash triage

When Phaedra finds a crash it deduplicates by signal number and input fingerprint. SIGSEGV and SIGABRT are CRITICAL. SIGILL and SIGFPE are HIGH. No-signal crashes are LOW. Each unique signature gets one entry in SQLite with a hit counter so if the same bug triggers 500 times you see one entry with hit_count=500, not 500 files in your crash directory.

phaedra crashes

ID  SEVERITY   HITS  SIGNATURE     STATUS
1   LOW        47    crash_3f2a1b  Crash { signal: None }
2   LOW        12    crash_7e4d2c  Crash { signal: None }

phaedra minimize runs delta minimization to reduce a crashing input to the smallest bytes that still trigger it. Found a 200-byte crash? It will usually get it down to under 10.

Try it

cargo install phaedra
phaedra fuzz --demo tlv

The TLV demo target has a real bounds-check bug. Phaedra finds it within the first few seconds.

GitHub: https://github.com/zaydmulani09/phaedra

I built a local token cost tracker for Claude Code in Rust

Zayd Mulani — Mon, 13 Jul 2026 21:58:53 +0000

After one too many surprise Claude Code bills, I built agentwatch.
It's a local HTTP proxy written in Rust. Point your agent at localhost:7878, and it intercepts every request, parses the token usage, and shows a live Ratatui TUI dashboard of what you're spending — in real time.
Everything stays local. SQLite database, zero signup, single binary via cargo install agentwatch.
Supports Claude Code, Codex, and Gemini CLI.
github.com/zaydmulani09/agentwatch

I built a self-hosted reverse proxy for MCP servers in Rust

Zayd Mulani — Thu, 02 Jul 2026 18:52:40 +0000

The problem

Every AI tool that talks to MCP servers (Claude, Cursor, etc.)
connects directly — no auth, no rate limiting, no observability.
You have no idea what's hitting your servers or how often.

What I built

MCP Gateway sits in front of all your MCP servers and handles:

Routing — /mcp/server-name/* proxies to the right backend
Auth — per-server API keys encrypted AES-256-GCM in memory
Rate limiting — token bucket per client, 429 + Retry-After
Logging — SQLite log of every request with latency + status
Usage tracking — token counts from Anthropic/OpenAI responses
CLI — mcpgw server add/list/remove, mcpgw logs show, mcpgw stats

Quickstart

MCPGW_MASTER_SECRET=your-secret docker compose up --build

Stack

Rust, Axum, SQLite (rusqlite), DashMap, AES-GCM

GitHub: https://github.com/zaydmulani09/mcp-gateway