DEV Community: NIRMEET TRIVEDI

I audited my own product and found it never actually worked for its own core use case

NIRMEET TRIVEDI — Sat, 12 Sep 2026 04:57:22 +0000

I built Meanwhile, a status line for Claude Code, Copilot CLI, and VS Code. Most of the time it shows a quiet tip. Sometimes it shows a clearly-labeled "(sponsored)" line instead, and when that happens half of what the sponsor paid goes back to the developer.

This week I actually sat down and audited my own code end to end instead of just checking install counts. What I found wasn't great: the VS Code extension had been silently broken for the exact use case it exists for, since the day it shipped.

Bug 1: the extension required a keystroke every 30 seconds

const ACTIVITY_FRESHNESS_MS = 30_000;

const poll = async () => {
  const windowFocused = vscode.window.state.focused;
  const recentlyActive = Date.now() - lastActivityAt < ACTIVITY_FRESHNESS_MS;
  if (!windowFocused || !recentlyActive) return;
  // ...fetch and bill a line...
};

lastActivityAt only updated on a real document edit. The moment you fire off an agent and take your hands off the keyboard to let it think, recentlyActive goes false within 30 seconds and the extension goes completely dark. That's the exact window the whole product exists to monetize.

Fix: track presence more broadly (tab switches, cursor movement, regaining window focus, not just edits), and widen the window to 5 minutes to actually match how long an agent turn runs.

Bug 2: even a live poll got flagged as fake

Independently, the server had its own gate:

function sessionProgressed(baseline, current) {
  if (!baseline) return true;
  if (current.tokens !== null && baseline.tokens !== null && current.tokens > baseline.tokens) return true;
  // ...
  return false;
}

For VS Code, tokens is mapped to the editor's own edit count. Requiring it to strictly increase makes sense for Claude Code (a real session's cost/tokens always climb turn over turn) but is exactly backwards for VS Code: edit count is supposed to plateau while you're waiting on an agent. So even after fixing bug 1, a genuinely live poll during a wait still got silently discarded as "looks like a faked ping."

Two independent bugs, stacked, both silently killing the same use case. Fixed by trusting a live poll within the same session (matched by session ID) instead of requiring a number that has no reason to move.

Bug 3: Copilot CLI only ever billed the first turn of a session

Copilot CLI's hook payload never sends cost or token data at all, just a session_id — and unlike Claude Code, that id doesn't change per turn, it's scoped to the whole CLI session. The server's fallback logic assumed a changing session id was the signal of real progression. Since Copilot's never changes within a session, every turn after the first billed $0, silently, for as long as the extension has existed.

The smaller stuff

Also found and fixed while in there:

/network-stats was doing a full sequential KV scan (600+ reads) on every request — replaced with a self-seeding Durable Object counter, now O(1)
A daily payout cron was writing install state directly to KV, bypassing the Durable Object that's supposed to be authoritative — a real double-payout risk
Abandoned advertiser checkouts were staying in a shared index forever, costing a KV read on every single status-line poll from every user
The Windows installer was missing a required config field the macOS/Linux one had
All three client scripts would hang forever if you ran them by hand to test (blocking on stdin with no TTY check)
The direct extension download on the site was still serving a build with bug 1 in it

None of this is retroactive marketing spin — if you installed the VS Code extension before this week and it felt dead, that was real, not you. It's fixed now (0.1.7, live on Open VSX).

I don't have big usage numbers to show off here. What I have is a real list of specific, embarrassing bugs, found by actually reading the code instead of trusting a dashboard, and fixed. If that's useful to anyone auditing their own "is this actually doing what I think it's doing" assumptions, that's the whole point of writing this up.

Your Cloudflare Workers KV rate limiter is probably attacking itself

NIRMEET TRIVEDI — Thu, 10 Sep 2026 05:36:17 +0000

I ship a small Cloudflare Worker (a Claude Code status line that pays users a cut of disclosed sponsor revenue -- not the point of this post, just context for where the traffic pattern came from). Every install polls /line every 10-20 seconds while the user is coding. That's a lot of requests hitting one Worker.

The setup that seemed fine

Rate limiting a Worker endpoint by install ID looks like a one-liner with KV:

async function checkLineRateLimit(env, installId) {
  const key = `ratelimit:${installId}`;
  const raw = await env.INSTALLS.get(key);
  const count = raw ? parseInt(raw, 10) : 0;
  if (count >= LIMIT) return { ok: false };
  await env.INSTALLS.put(key, String(count + 1), { expirationTtl: WINDOW_SECONDS });
  return { ok: true };
}

This worked in testing. It broke in production, and not because of an attack -- just real usage at real scale.

Where it actually breaks

Workers KV on the free plan has an account-wide cap: 100,000 get() reads per day, not per namespace, not per key. Every single /line call was doing a get() just to check the rate limit, before it ever touched the actual install data. At normal polling frequency across a few hundred concurrent installs, that hot-path read alone was enough to burn through the daily quota -- and once it's gone, it's gone until midnight UTC. Every KV get() anywhere in the account starts failing with a hard error, including reads that have nothing to do with rate limiting.

The failure mode is brutal because it's silent until it isn't: everything works fine right up until the exact moment the account-wide counter ticks over, and then every /line call in production starts 500ing at once.

The fix: stop asking KV a question the cache API can already answer

The rate limit check doesn't need durability. It doesn't need to survive a Worker restart. It just needs to answer "has this install called recently" for a few seconds, cheaply, at massive read volume. That's exactly what the platform's own edge cache is for, and unlike KV, caches.default reads don't count against any daily read quota at all:

async function checkLineRateLimit(env, installId) {
  const cache = caches.default;
  const cacheKey = new Request(
    `https://ratelimit.internal/line/install/${encodeURIComponent(installId)}`
  );
  try {
    const cached = await cache.match(cacheKey);
    const count = cached ? parseInt(await cached.text(), 10) : 0;
    if (count >= LIMIT) return { ok: false };
    await cache.put(
      cacheKey,
      new Response(String(count + 1), {
        headers: { "cache-control": `max-age=${WINDOW_SECONDS}` },
      })
    );
  } catch (e) {
    // fail open: a rate-limit check failing should never break the real request
  }
  return { ok: true };
}

Same interface, same call site, zero KV reads for this path. The try/catch matters as much as the cache swap: a rate limiter is a defensive layer, and defensive layers should fail open, not become a second way for the app to go down.

The part that isn't about caching at all

Fixing the hot path wasn't enough on its own, because the actual install data reads (not the rate limit, the real per-user state) were still hitting KV directly on every call. I moved those onto a Durable Object, one instance per install (idFromName(installId)), so KV is only touched once -- on that instance's true cold start -- and every call after that is served from the DO's own durable storage. The DO mirrors writes back to KV asynchronously so anything else that reads install:<id> directly out of KV (an admin dashboard, a cron job) still sees current data without knowing the DO exists.

The general shape of the fix, not just for this bug: if something is read on every request and doesn't strictly need cross-region strong consistency, it probably shouldn't be sharing a quota with your actual source-of-truth reads. Splitting "is this allowed" from "what's the data" onto different storage tiers means a hot path can run as hot as it wants without threatening to take down everything else sharing that account.

I built a status line that pays you while your AI coding agent thinks

NIRMEET TRIVEDI — Mon, 07 Sep 2026 12:53:41 +0000

I'm 14, and I got tired of watching Claude Code's spinner sit there doing nothing for money. So I built Meanwhile -- a status line that shows a clearly disclosed sponsor line while your AI agent is thinking, and pays you a real cut for it.

What it does

npx trymeanwhile wires into Claude Code's (or Copilot CLI's) own supported statusLine setting -- nothing patches your machine. While your agent is working, the line rotates between plain tips and occasional sponsor lines. Every sponsor line is labeled as sponsored, always. You split what it earns, 50/50, paid out automatically.

How it's built

The backend is entirely Cloudflare Workers:

Durable Objects serialize concurrent impression-count writes. I stress-tested plain KV read-modify-write under concurrent requests and it was losing 18 out of 20 increments -- classic race condition. A Durable Object per ad campaign (via idFromName) fixed that completely, since it processes requests for that campaign one at a time.
Workers AI (@cf/meta/llama-3.2-3b-instruct) generates a chunk of the non-sponsor tip lines, with a hard timeout fallback so a slow model call never blocks your status line from rendering.
KV handles per-install state, rate-limiting, and session baselines.

The billing signal

The whole thing only bills a line if it actually stayed on screen for 10+ seconds -- so it's tied to real thinking time, not just an API call firing.

Try it

npx trymeanwhile

Restart your tool and you're in. Check what you've earned with npx trymeanwhile claim.

Live at trymeanwhile.online. Would genuinely love feedback, especially from anyone who's dealt with concurrency bugs like the KV one above -- curious if there's a cleaner pattern I'm missing.