DEV Community: Ritabrata Maiti

Every $20 AI subscription costs about $100 to serve. The bill is coming.

Ritabrata Maiti — Thu, 24 Sep 2026 08:33:39 +0000

A piece called
AI subscriptions are a ticking time bomb for enterprise
made the rounds this week, and the headline is the right shape of the
story. Every major AI lab is running an industry-wide loss-leader at a
scale that does not really have a precedent. Your company's $20 Claude
Pro seats and $20 ChatGPT Plus seats are being served at something
like five times the cost the lab is collecting for them, and that
arrangement is not stable.

The price tag has not moved in three years. The product has changed
completely.

The unit economics

A Claude Pro seat is $20 a month and gives you Sonnet 4.6, Opus 4.6,
file creation, code execution, web search. On the API, those same
models cost $3 input and $15 output per million tokens for Sonnet,
$5 input and $25 output for Opus. A knowledge worker running Claude
for a few hours a day, uploading documents, drafting reports, easily
moves through enough tokens that the API-priced equivalent of that
seat sits somewhere between $200 and $400 a month.

Microsoft was reportedly losing more than $20 a month on every GitHub
Copilot seat. Power users were hitting $80. One widely-cited analysis
found Anthropic was burning about $8 of compute for every $1 of
subscription revenue. The $20 sticker has been frozen since 2022 and
the models in that window picked up image generation, code execution,
voice, agentic reasoning, web search, and a generational capability
jump. The number stayed put.

That is the whole story. Everything from here is mechanism.

What the subsidy was buying

Cheap inference at consumer prices, deployed broadly to enterprises,
was buying integration depth. The labs were not trying to make money
on the seat. They were trying to make sure the seat existed in the
first place, then make sure the company's marketing draft and the
engineer's pull request review and the analyst's quarterly summary
all happened through it. Once those workflows are load-bearing, the
price can move. The dependency is the asset.

You can see this in the language coming out of OpenAI. Nick Turley,
their VP of product, described the subscription pricing as something
they
stumbled into,
and has floated phasing out unlimited plans entirely, comparing them
to "unlimited electricity." Sam Altman said publicly that OpenAI now
needs to become "an AI inference company," which is the polite version
of admitting the consumer subscription was a customer-acquisition line
item, not a P&L.

The KPMG Q1 2026 pulse has U.S. organizations projecting average AI
spending of $207 million over the next twelve months, roughly double
the year before. A Goldman Sachs survey of large companies has most
of them overrunning their AI budgets by orders of magnitude.
Chandrasekaran, who runs AI and data at KPMG North America, told
Marketplace
the quiet part: "Even a quarter or two ago nobody bothered about LLM
consumption costs." It is the bother stage now.

Agents are what broke the math

The reason the subsidy held as long as it did is that AI was a chatbot.
You typed, it answered, you read the answer, repeat. A normal session
was a few thousand tokens. Heavy use ran into the tens of thousands.
At those volumes, $20 a seat was uncomfortable for the lab but not
catastrophic.

Agents do not look like that.

A Claude Code session runs autonomously for an extended period. It
reads files, writes files, runs commands, looks at the output, decides
what to do next, repeats. Users have been
exhausting five-hour rate-limit windows in under ninety minutes.
Multiple agents in parallel on a single project multiply that. A
developer running three or four concurrent coding agents is consuming
something close to an order of magnitude more tokens than the same
person in chat, and the subscription price on the seat is unchanged.

GitHub took the obvious next step. On June 1, 2026, Copilot
moves to usage-based billing,
specifically because the flat-fee model collapsed under agentic
workloads. The announcement spelled it out: agentic usage is becoming
the default, the inference demand is qualitatively different, the
pricing has to follow.

Everyone else will do the same thing on a delay.

The enterprise position

This is where it gets ugly for organizations that have not done the
work.

Over the past two years, thousands of companies have woven $20 AI
subscriptions deep into operations. Marketing drafts copy through
ChatGPT Plus. Engineering writes and reviews code through Claude Pro.
Research synthesizes documents. Customer success summarizes tickets.
Finance models scenarios. The line items are budgeted at subsidized
prices because that is what the bill currently says. The actual cost
of the same workloads at API rates, if the lab were charging it, is
fifteen to twenty times higher.

When prices adjust, two things happen at once. The bill goes up, and
the workflows are already too embedded to rip out. The subsidy creates
the dependency, the dependency makes the price increase unavoidable.
That is the trap, and there is no clever way out of it.

The companies that survive this transition cleanly will be the ones
that did the bookkeeping. Track per-team token consumption. Know which
workflows are genuinely high-value and which are running Claude on
something a 2018 script could have done. Have a sense of which
subscriptions can move to per-seat billing if it has to, and which
ones become structurally expensive overnight.

The companies that don't survive cleanly will discover the bill in
the third week of whichever month the subsidy ends, with no time to
re-budget and no leverage to renegotiate.

What it means for agent tools

The shake-out hits the agent tool market harder than it hits the labs.
The labs are losing on the seat, but they own the inference. They can
move the price. They can change the plan. They can introduce
usage-based tiers and call them "for power users." The seat is still
there at the end.

The agent tool, the wrapper, the IDE plugin, the browser extension
that uses the lab's API or subscription on your behalf, is in a worse
position. If it has its own per-seat subscription, it is selling you
something whose underlying cost just doubled, and it has to either eat
that or pass it on. If it bills on its own meter on top of the lab's,
it is asking enterprises to swallow a usage line item that already had
no budget code.

The agent tools that survive the next twelve months will be the ones
that don't sell their own meter. Tools that piggyback on the
subscription the user already has. Tools that don't introduce a second
billing surface for finance to police. Tools whose cost curve is
shaped by the lab's pricing, not by the tool's overhead.

This is not a clever positioning argument. It is what happens to every
software-on-top-of-software market when the underlying utility starts
charging real prices. The tools that own the price stack survive. The
tools that resell the utility at a markup get squeezed.

A note on what I work on

I build Browy, an open-source AI agent that lives
in a Chrome side panel and a DevTools REPL. It drives the real browser
tabs you have open. The thing it does not have is its own subscription.
It uses your existing
GitHub Copilot subscription for
the model. The model call goes from your machine to GitHub, the answer
comes back, the rest happens locally.

When Copilot moves to usage-based billing on June 1, you pay GitHub
the new rate, the same as you would have anyway. Browy doesn't sit
between you and that bill. It doesn't add a per-seat charge of its
own. It doesn't run a metered tier on top. That is not a special
business decision on our end, it is the only decision that survives
the shake-out described above. The tools that try to live on top of a
collapsing subsidy by adding their own subsidy get squeezed twice.

That is most of the story I wanted to put down. The original piece is
here.
The 30-second video version is at the top of this post.

All posts Index of every post on the Browy blog.
AI slop killed the open-source bug bounty Earlier essay on the other end of the same arc: cheap inference, not yet expensive.

Google quietly declared war on the open web.

Ritabrata Maiti — Thu, 24 Sep 2026 08:32:53 +0000

At Google I/O this week, the Search team made AI Overviews the default
answer surface for English users. The
official keynote post
buries the change under a lot of "agentic" and "personal intelligence"
language, but the practical effect is small and definite: Search now
answers from a Google-hosted synthesis. The blue links are a fallback,
not the product.

This was the inevitable next step of a series of changes that started
with featured snippets and accelerated with AI Overviews. The
10 percent inaccuracy rate
on AI Overviews is now everyone's problem, because Overviews are
everyone's default answer.

The
piece on tante.cc
called this "declaring war on the web," and the wording is exactly
right. What follows is what I think the change actually is, the deal
that broke, and what to do about it.

The deal that built the web

Sites let Google crawl them. Google sent traffic back. Both sides
won. The crawler got fresh content; the site got readers, and the
readers had a clear path back to the source when they wanted to dig
deeper.

This contract held for about twenty years. It built the open web as
a publishing surface, the indie blog as a thing that paid rent, the
SEO industry, the long-tail of niche reference sites, and most of
what we now call "documentation on the internet." It was an
asymmetric trade, but both sides understood it. You give Google the
catalog. Google sends you the foot traffic.

AI Overviews quietly cancelled the trade.

The crawler still runs. The catalog still gets ingested. The output
on the user's screen is now a Google-synthesised answer, with the
sources demoted to a row of tiny chip-shaped citations the median
user does not click. The reader gets an answer, often correct,
sometimes wrong, and never has to leave the search results page.

What this is, named plainly

The framing in the original piece is sharp and worth quoting at
length:

Your work, your writing or art do matter a bit still: As (unpaid)
raw material for their synthetic text extruders. You get to work
for free so Google can have tight control on the flow of
information and make sure that the responses people get are in
line with what they need them to be.

This is the right frame. The web is not the product anymore. The
web is the raw material. The product is the synthesised view on top
of it, hosted on Google's infrastructure, branded with Google's UI,
and accountable to Google's editorial choices.

A useful analogy: the relationship between a wire service and a
newspaper. The wire produces the underlying reporting; the newspaper
picks, edits, and presents. The reader sees the newspaper. For a
long time the web was the newspaper. Google was the index, the table
of contents that pointed at the newspaper. AI Overviews flipped that.
Google is the newspaper now. Your site is the wire.

The thing that makes this disorienting is that nobody negotiated the
new arrangement. The publishers did not agree to be wire
contributors. The wire contributors did not get paid. The newspaper
masthead never asked.

Why this is bigger than search-traffic math

The temptation is to treat this as an SEO problem. Traffic numbers
will drop, sites will adapt, the market will sort it out. That misses
the scale.

Google holds the largest single browser deployment on the planet,
the largest single mobile OS, the largest single web video platform,
the dominant share of web standards committee participation, the
dominant share of ad-tech, and now the dominant search-answer
surface. A single company sets the abstraction layer at every point
between the publisher and the reader. When that company decides the
abstraction layer should not include outbound links, there is no
counter-party large enough to disagree at scale.

This is the part the SEO frame misses. The market does not have a
way to sort out a question of this scale because the market does not
have a participant of this scale. The closest analogue is regulatory.
The EU has begun acting. The DOJ case is grinding along. Neither is
fast enough to matter at the speed Google can ship.

The web is going to survive this. The independent publisher, the
solo blog, the niche reference site, the corner of the internet
written by one human for fifteen others, will get squeezed in the
process. Some will respond by exiting. Some will paywall. Some will
move to Substack or to mailing lists, which is just running their own
distribution stack. The shape of the open web will change a lot,
faster than the SEO market expects.

What you can do as a user

The advice older than the problem still applies. Run your own tools.
Pick your own sources. Don't outsource your reading to a system whose
incentives are to keep you on its surface.

Concretely:

Use a search engine that links out. Kagi, Marginalia, Mojeek, Searx, DuckDuckGo, Brave Search. None are perfect, all are linking out by default. The web still indexes; the index is just not the default surface anymore.
Keep an RSS reader. Feedbin, Inoreader, NetNewsWire on the Mac, Readwise Reader if you want web archiving. Subscribing directly to the publishers you trust routes you around the answer-surface entirely.
Build a personal allowlist of go-to sources. The handful of sites you check first when you want a real answer. For me that's about thirty sites; the search engine is where I go when none of them have it. This is roughly how everyone used the web in 2005.
Read source material when the stakes are high. AI Overviews are wrong 10 percent of the time. That rate is fine for "what is the recipe for pancakes." It is not fine for "what does this medication interact with."

The pattern is the same in each case: keep the human in the loop
when the cost of wrong is high, and let the machine condense when the
cost of wrong is low.

What this has to do with what I build

I work on Browy, an open-source AI agent that
lives in a Chromium extension. It drives the real browser tab you
have open. You ask it a question; it inspects the page, follows
links, reads other tabs, and writes you an answer with the sources
visible inline. It does not synthesise from a hosted index. It
operates on the web you would see if you were doing the work yourself.

That is not a coincidence. It is the response to exactly the
disintermediation move described above. If the answer-surface is
hosted by a counter-party whose incentives are not yours, the answer
you want is the one you can produce yourself, against the sources
you trust, on the page that loaded in front of you.

The web is not ending. The middleman is trying to swallow it. Run
your own tools.

All posts Index of every post on the Browy blog.

GitHub got pwned through one VSCode extension. 3,800 repos.

Ritabrata Maiti — Thu, 24 Sep 2026 08:32:12 +0000

GitHub confirmed this week that roughly 3,800 of its internal
repositories were exfiltrated after one of its own employees installed
a trojanised version of the Nx Console extension for VSCode. The
malicious extension came through the official VS Code Marketplace, ran
with the editor's permissions, and quietly handed back the contents of
the employee's repo cache. GitHub has since linked the campaign to the
TanStack npm supply chain attack
from earlier this month and removed the poisoned extension from the
marketplace.

The TeamPCP group is asking $50,000 for the dump. As far as anyone
outside GitHub can tell, no customer data has moved.

That is the news. The interesting part is the design that made it
possible.

The editor has no sandbox

A VSCode extension runs as Node.js code inside the editor's process.
It has the editor's permissions. That means it can read every file in
every workspace you have ever opened, every token in your
~/.aws/credentials, every entry in your SSH agent, and every byte
that ever passed through git push. The Marketplace itself has no
sandbox model. There has been
a feature request open since 2018
asking Microsoft to ship one. The request is still open.

This is not a VSCode-specific complaint. It is the model. Cursor
inherits the architecture. Windsurf inherits it. JetBrains plugins
run with the IDE's permissions, just packaged differently. Vim and
Emacs have had this problem since plugins were invented; the only
reason it never blew up at this scale is that nobody put a marketplace
in front of them.

The Marketplace is the part that scales the blast radius. Twelve
months ago, a set of malicious extensions disguised as legitimate
tools racked up
9 million installs
before takedown. A different set posed as
cryptominer-laden helpers.
A WhiteCobra-flooded batch of twenty-four extensions, one of them with
basic ransomware capability,
made it onto the marketplace before anyone noticed. And in January, a
pair of malicious AI-coding-assistant extensions with
1.5 million installs
silently shipped developer data to servers in China.

Add it up. Across the visible-to-the-public campaigns, this is more
than 11 million installs of code that should not have been there. The
GitHub breach is one well-placed install away from "any of the above
got an SRE."

The bug, named honestly

The threat model in this story is not a clever attacker. The threat
model is a checkbox the operator did not read carefully because they
were trying to get work done.

A developer at GitHub had an editor open. The editor said: install
this extension. It looked like Nx Console; the developer needed Nx
Console. They clicked install. Three thousand eight hundred internal
repos went out the back door. There is no version of "be more
careful" that fixes this. The marketplace is the install surface and
the marketplace cannot, in its current shape, distinguish the real
extension from the malicious one with the same name.

The fix is at the layer the operator doesn't have to think about.
That is either:

The editor ships a sandbox. Extensions ask for the file paths, network endpoints, and OS capabilities they need. The user reviews a manifest, the same way they review extension permissions in a browser. Microsoft has been promising this since 2018.
The marketplace adds an integrity layer that an attacker cannot forge. Reproducible builds, source mirroring, signed releases. Nothing on the marketplace today provides this end to end.
The user installs nothing they have not personally read or that does not come from a vendor whose source they can audit.

Option 3 is the only one available today. Options 1 and 2 require
Microsoft to ship work that has been promised for seven years.

Why this matters for browser extensions

I work on a browser extension, so I want to be clear about what does
and does not transfer from this story.

Chromium MV3 extensions are not VSCode extensions. The permission
model is real. An extension declares the URLs it can touch
(host_permissions) and the capabilities it can use (debugger,
storage, nativeMessaging, and so on) in manifest.json. The
browser enforces those declarations. An extension that says
"host_permissions": ["https://gmail.com/*"] literally cannot reach
bank.example.com. The Chrome Web Store review process is not
perfect, but it does look at the manifest before publish.

That makes the browser-extension surface meaningfully better than the
editor-extension surface for the same class of attack. It does not
make it safe. Things to watch:

<all_urls> is a real permission Chrome will grant if the user agrees. Many general-purpose extensions ask for it. Browy asks for it (we have to; you point us at any tab you visit). What stops abuse is the next thing on the list.
The CRX you download is signed. It is not necessarily the source you read. Chrome Web Store does not require reproducible builds. If the vendor publishes obfuscated code, you are trusting the vendor, not the code.
Native messaging is the escape hatch. Browy has a native host that runs on your machine. So does any "remote control" extension, any password manager native bridge, and many "AI assistants." A malicious extension can ship a clean source repo and a malicious native binary, and the user has no easy way to know.

The list of things that would help Chrome users defend themselves is
roughly the same as for VSCode users: a sandbox the user reviews, a
marketplace integrity layer the attacker cannot forge, and a habit of
installing nothing whose source you have not read.

What I do about this in Browy

Browy is open-source under Apache-2.0. The
source ships in the release. The
agent loop is in one file
and the
tool registry is in another.
A reviewer who reads either file in twenty minutes has read the
attack surface. There is no Browy server. The model call goes from
your machine to GitHub Copilot via the local Copilot CLI; everything
else is local.

The host-touching tools (bash, read_file, write_file, grep,
glob, web_fetch) are off by default. To use any of them you have
to open Settings, find the tool, and turn it on. The browser-driving
tools are on by default but each can be turned off the same way. We
ship a debugger banner whenever a session is live, because Chrome
makes that mandatory and we are happy with that.

None of this prevents a future me from going rogue and shipping a
malicious release. It does mean that anyone who cares can pin a
known-good build, audit any future build before installing, and run
their own from source. The fix for the marketplace problem is not a
better marketplace. It is a habit of looking at what you install.

The short version: when the editor has no sandbox, the only sandbox
left is your attention. Spend it before you click install, not after.

All posts Index of every post on the Browy blog.
AI slop killed the open-source bug bounty The other end of the same arc: cheap inference, asymmetric inbox, maintainer attention as the limiting factor.

AI slop killed the open-source bug bounty

Ritabrata Maiti — Thu, 24 Sep 2026 08:31:31 +0000

Turso, the SQLite-compatible database written in Rust, retired its bug
bounty program this week. The post explaining why is titled, dryly,
The wonders of AI. For
about a year the project had been paying $1,000 for each critical
vulnerability someone reported in the codebase. Budget wasn't the
problem. The problem was that most of the reports landing in the
maintainer's inbox were written by an LLM, and the maintainer was
spending most of his bounty hours reading text that no human had really
intended for him to read.

The examples are funny in a bleak way. One submission claimed to have
found a critical flaw that let an attacker execute arbitrary SQL
statements. Against a SQL database. Another report on the same project
described a buffer overflow whose reproduction steps included editing
Turso's own source code, recompiling with a forced volatile write past
the end of a vector, and running the modified binary. The "vulnerable
code paths" did not exist. The "exploits" did not reproduce.

So the maintainers ended the program. That is a small story about one
database, and also a very large story about every queue on the internet
that involves humans on one side and an open submission form on the
other. Every maintainer who has read Turso's post this week has
recognised their own inbox.

The contract that worked

The economics of a bug bounty are tidy. The project says: if you find a
real problem that meets this severity bar, we pay you $X. Both sides
win. The hunter gets paid for genuinely useful work. The project gets
a security audit it could not have afforded any other way.

That contract rested on a quiet assumption. The cost of submitting a
report was supposed to be in the same neighbourhood as the cost of
producing one. Producing a real exploit is hard. Writing one up takes
hours. So submission volume self-throttled. The queue stayed roughly
the size of the real-findings rate, which is the rate a small team can
actually triage.

Cheap inference broke that assumption in about eighteen months.

What changed

It now costs roughly a tenth of a cent to ask a frontier model to
produce a vulnerability report against a public codebase. The model
will produce one. The report will look real enough that a human has to
spend about ten minutes reading it before concluding that it isn't.
Submission is effectively free. Triage costs the most expensive thing
a software project has, which is the unbroken attention of the one
person who understands the code.

You don't need many people running that arbitrage to break a small
program. Once the submission rate climbs past the triage rate, the
queue does not stabilise. It grows until the maintainer either gives
up reading or gives up the program. Turso gave up the program.

The same shape, everywhere

The bug bounty story is just one shape of a pattern that is now visible
in a dozen places.

Drive-by pull requests are flooding popular GitHub repos. Most are
LLM-generated typo fixes or hallucinated refactors. Maintainers either
auto-close everything and lose the legitimate ones, or burn out on
triage. Open issue trackers are seeing the same flood of "I think there
might be a bug" reports with no reproduction, often filed by a chatbot
middle layer that promised a confused user it would "let the developers
know." Code review comments are now arriving thirty at a time on small
PRs, mostly tautologies and hedges. The comment threads on technical
blog posts are heading the same way.

The shape is always the same. Producing the input costs nothing.
Processing the input still costs a person.

We have automated finding bugs. We have automated submitting bugs. This
year we are automating rejecting bugs. Nobody is automating fixing them.

The bottleneck was never the writing

A lot of the early excitement about LLMs in software was that they
could write code very fast. That turned out to be true, and it turned
out to be the less interesting half of the problem. Writing the code
was never the bottleneck. Reading the code is the bottleneck. Reviewing
the code, understanding the code, deciding whether to merge the code,
deciding whether to ship the code, deciding what to do when the code
breaks at 2am. The reading-and-deciding loop is where engineering
actually happens, and it has always been bounded by how many things a
human can hold in their head at once.

LLMs add to the writing side of that loop and add to the input side of
every queue feeding into it. They don't move the reading-and-deciding
bottleneck. They make it the limiting factor for almost everything.

This is why "just put an AI in the triage loop" doesn't fix the Turso
problem. If there's a model deciding which reports a human sees,
you've created a new game: produce reports that pass the model. That
game is also cheap to play. The judgment step that the attacker is
trying to commodify is the exact step that has to stay with a person,
because that's what was being attacked in the first place.

What might actually hold

A handful of patterns are starting to circulate in maintainer
conversations. None are clean.

A refundable submission deposit is the most-discussed option. You put
down a small amount, say $20. You get it back if the report holds up.
You lose it if it's slop. The economics work. The downside is that it
filters out the hobbyist newcomer who doesn't have a card on file,
which is exactly the population the open programs were designed to
find.

Reputation gating goes the other way. First-time submitters have to
clear a higher bar, including a full reproduction and a vouching
introduction. Established hunters skip the bar. This rebuilds an
apprenticeship model that hasn't really existed in software security
for a generation, but it raises the cost of discovering new talent.

A few projects have started running honeypots. The clearest example is
UnsafeLabs/Bounty-Hunters,
which publishes a bounty-shaped repo that exists mainly to attract
automated scanners. The submissions feed a public
leaderboard of automated submitters.
You can read it as petty, or you can read it as the first attempt at
something a search-engine spam team would recognise: a shared blocklist
for the actor side of an asymmetric inbox problem.

Some teams are moving programs off public surfaces entirely and onto
verified-identity platforms like HackerOne or Bugcrowd, where the
platform handles attribution. Small projects can't usually afford the
platform fees. Bigger ones lose the discovery effect of an open
program.

The most interesting idea I've seen circulating among maintainers is
what someone called proof of code. Before you can submit a bounty
report, you have to land a small, accepted PR somewhere in the
project. The PR doesn't have to be security-related. It just has to be
real engineering by a person who understood the surrounding code. That
converts a cheap text-generation game into a more expensive engineering
game. It doesn't solve the problem. It tilts the asymmetry the other
way.

This is bigger than bounties

The same dynamic is coming for everything that depends on an open
queue with humans on the receiving end. Customer support tickets.
Conference paper submissions. Open peer review. Public consultation
periods on regulation. Government FOIA requests. Hiring inboxes. The
comment thread under this post, probably.

The economic concept is older than the internet. It is the tragedy of
the commons applied to attention instead of grazing land. What's new
is the rate at which the cost of producing input is falling. Most of
the institutions that grew up around the old cost curve don't have
time to redesign before the next drop.

The next decade of public-facing system design is going to be about
adding friction back in on purpose. Identity. Deposits. Reputation.
Proof of work. Vouching. We spent twenty years stripping friction out
of every form on the internet because friction was the enemy of
growth. Now friction is the only thing protecting the people on the
receiving end of those forms. The companies that figure out how to add
it without losing the magic are going to eat everyone else.

A note on what "AI agent" means

There are two things people now mean by "AI agent," and they are
nearly opposite.

One is the slop pipeline that broke Turso. Cheap inference pointed at
any open queue, with no human in the loop, generating volume that
other humans then have to filter. The person whose name is on the
submission usually isn't watching what's submitted. Often they don't
even know what was submitted.

The other is the tool a person uses to do their actual work. An agent
that drives the browser tab they're sitting in front of, that reads
the codebase they're working on, that runs the command they would
have typed. The person is at the keyboard. They see every action.
Nothing gets sent to anyone else's queue without them watching it
happen.

These two things share a phrase and almost nothing else. The first one
is a tax on every public surface on the internet. The second one is a
power tool. The fact that they have the same name in the press is
going to cost the second category a lot of goodwill before things
sort themselves out.

I work on the second kind. Browy is an
open-source AI agent that lives in a Chrome side panel and a DevTools
REPL. It drives your real browser tabs through chat. There is no Browy
server in the loop. There is no inbox you can flood by talking to it.
There is a person, you, watching every click and every form fill it
makes. Whatever happens to the public commons over the next few years,
the part of the internet that's a tool you operate yourself is still
going to be a good place to live.

The 30-second video version of this argument is at the top of this
post. Turso's own write-up is
here.

All posts Index of every post on the Browy blog.
Mullvad gave you 8 trillion exit IPs. 9 servers found you. Same researcher-pattern thinking, different domain: a VPN whose deterministic IP picker leaks identity across servers.

Mullvad gave you 8 trillion exit IPs. 9 servers found you.

Ritabrata Maiti — Thu, 24 Sep 2026 08:30:05 +0000

Mullvad is one of the few VPN providers that hands you a different public
IP for each of its servers. With 578 servers in the fleet, a naive
calculation gives you over 8 trillion possible combinations of exit IPs
across the network. The pitch is that you melt into a very large crowd.

A researcher who writes as tmctmt sat down with a script, rotated through
3,650 WireGuard keys, and watched which exit IPs each key was assigned
across nine servers. They expected to see thousands of distinct
combinations. They saw 284. The
full write-up is here.

The cause is unglamorous and the impact is not.

How the picker works

When you connect to a Mullvad server, the exit IP you get is not random.
It is picked deterministically from a per-server pool, seeded by your
WireGuard public key. The pool sizes vary by server. Sydney exposes 60
IPs, Helsinki 66, Los Angeles 91, Santiago 11. The key rotates every
one to thirty days if you use the official app, and never if you bring
your own WireGuard client.

So far so reasonable. Per-key stickiness avoids hammering a single
external IP with users who reconnect every few minutes, and it lets
sites that ratelimit by IP behave sanely for a Mullvad user inside one
session.

The problem is the picker itself.

One float, many pools

The picker seeds a standard library RNG with the pubkey, then draws a
single floating point number in the range zero to one. It scales that
float to the size of the current server's pool to produce an index.
That part is plausible. The part that breaks privacy is that the float
is the same float on every server, because the RNG is seeded with the
same pubkey and only the upper bound changes between calls.

The consequence is that your exit IPs across servers land in the same
percentile of each pool. If your float happens to be 0.82, you sit at
position 49 of 60 in Sydney, position 9 of 11 in Santiago, position 54
of 66 in Helsinki. Different IPs, same relative slot.

If you have ever wondered why two of the smaller Mullvad servers seem
to give you the "same" index, this is why. Santiago and Johannesburg
both have pools of 11. With the same float scaled to the same size,
they hand you the same position.

Why 8.2 trillion collapsed to 284

This is the headline of the post. The pool sizes multiply to 8.2 trillion
on paper. In practice the float is one number, so the entire vector of
exit IPs across all servers is parameterised by that one number. The
researcher's 3,650 sampled pubkeys produced only 284 distinct
combinations across nine servers because the space being sampled is
not thirteen-dimensional. It is one-dimensional, then projected.

The 284 figure is the resolution of that projection at nine servers.
With more servers the resolution rises, because each additional pool
size carves the unit interval into finer buckets. With fewer servers
it drops, but it does not drop as much as you would hope.

What that means for a user

The author built a small tool that takes a set of observed exit IPs and
back-solves for the float interval that produced them. Nine well-chosen
exit IPs squeeze the interval down to roughly 0.0034 wide. At an
estimated 100,000 active Mullvad users that is around 340 people.

Three hundred and forty is a lot of people in a crowd. It is not a lot
of people in a deanonymisation attack. If a forum has IP logs and
suspects two accounts are the same user, and the two accounts both
connected through Mullvad on different servers, the overlap of the
float intervals derived from those exits gives a very high probability
that the accounts share a pubkey. Pair that with timing, user agent,
language headers, or the kind of low-effort browser fingerprint that
ad networks already collect, and the pool of suspects shrinks to one.

The interesting attack is not a moderator with one forum's logs. It is
the joining of logs across services that already happens in litigation,
in subpoenas, and in stolen breach data. Mullvad's per-server IP
diversity stops being a defence the moment two unrelated services
contribute their exit IP records to the same correlation.

The response

Mullvad's co-founder posted a response on the morning the article went
up. The short version: some of the described behaviour was intentional,
some was not, the unintended part is being patched on a subset of the
fleet first, and the intended part is now under internal review. He
also asked, gently, that future researchers consider notifying the
vendor before publishing.

That is about the best response a small vendor can give to a Tuesday
morning surprise, and it points at the part of this story that is most
worth sitting with.

The bug under the bug

The proximate bug is a seeded RNG whose first draw was treated as a
fresh random number per call, when it is the same number every call.
A defensible code review could miss this. The Rust documentation does
not put the behaviour on a billboard, and the test that would have
caught it, "do my exit IP percentiles correlate across pools," is not
the test anyone writes.

The deeper bug is the design assumption that per-key stickiness is
compatible with per-server independence. It is not, for any picker
that derives its index from a single seeded float. To get true
independence you have to either reseed per call with a per-server salt,
or pre-mix the pubkey with the server identity before drawing, or
abandon determinism and accept the operational cost.

There is a clean lesson here about cryptographic determinism that I
will not labour, but the practical one for anyone shipping
privacy-flavoured software is worth saying out loud. Deterministic
behaviour is the thing that makes user experience predictable and the
thing that makes users linkable across observations. The instinct to
make a system feel coherent across sessions is the same instinct that
hands an analyst a join key.

What a user can do today

The author lists two mitigations. Both reduce the value of the
fingerprint without removing it.

The first is to avoid switching servers while your pubkey is unchanged.
If you only ever connect from one Mullvad server, an observer sees one
exit IP and gets one of the pool's possible float intervals, not the
intersection of many. That interval covers a much larger share of the
user base.

The second is to force-rotate your pubkey, which the Mullvad app will
do if you log out and log back in. A new pubkey produces a new float
and a new vector of exit IPs. Past observations of you, before the
rotation, still link to whatever activity happened under the old key.

Neither of these is satisfying. Both are what the user can do until
the patch lands.

The bigger picture for privacy tools

VPNs are sold as a tool for blending in. The category has spent ten
years competing on server count, jurisdiction, and "we don't log."
None of that helps if the tunnel itself emits a stable signal that
correlates across exits. Mullvad is one of the better-regarded
operators in the category, run by people who care about this stuff
and respond like it. If this design slipped past them, it is worth
assuming similar designs are sitting unexamined in operators who
care less.

The healthier framing for anyone using a privacy tool is that the tool
moves the boundary of who can see you. It does not make you invisible
to the people inside the new boundary. A VPN protects you from your
ISP and from the cafe Wi-Fi. It does not protect you from the website
you are visiting, which still sees your browser, your timing, and
whatever your tunnel happens to leak about your identity across
sessions. Pretending otherwise is how people end up surprised.

What this has to do with browsers

A lot of the leak surface in modern web sessions is in the browser,
not in the tunnel. Canvas fingerprinting, font enumeration, audio
context fingerprinting, third party cookies that you thought were
blocked, redirect chains that smuggle identifiers in the URL, the
clipboard, the way your tabs talk to each other, the way an extension
you forgot you installed talks to its origin. The interesting thing
about the Mullvad story is that it is one of the rare cases where the
leak is below the browser, and the browser would not see it without
help.

I work on Browy, an open-source AI agent that
lives in a Chrome side panel and a DevTools REPL. It drives the real
tab you are looking at. You can point it at a page and ask, in
English, what the page is sending, what it stores, what it loads from
where, what it is trying to identify you with. It will open the
Network tab and the Application tab and read them for you, and it
will tell you what it found in the same chat where you asked the
question. It does not send your browsing anywhere. The model call
goes out and the answer comes back, the rest happens on your machine.

The Mullvad bug is a server-side problem. Browy will not see it. But
the broader habit, watching what your browser actually emits while
you are using it, is what every category of privacy leak in the last
decade has rewarded. The 30-second video version of the Mullvad story
is at the top of this post. The full research, with the seed
estimator tool, is
at tmctmt's site.

All posts Index of every post on the Browy blog.
AI slop killed the open-source bug bounty The same shape in software security: a real database project just retired its bounty program because AI submissions broke the queue.

AnyModal: Train Multimodal LLMs in PyTorch

Ritabrata Maiti — Tue, 19 Nov 2024 11:13:42 +0000

Today, I want to introduce an open-source framework I’ve been working on: AnyModal.

Introduction

During my work on machine learning projects, I struggled to find flexible solutions for training multimodal LLMs. While there are plenty of great tools for specific tasks—like image classification or audio processing—there was no straightforward way to combine these modalities with large language models (LLMs). The process was often tedious, involving boilerplate code, custom integration, and a lot of trial and error to make different components work together.

This frustration led me to build AnyModal, a framework designed to reduce the complexity of multimodal AI development. It provides a modular, reusable structure that makes it easier for developers and researchers to combine diverse data types and experiment with new ideas without reinventing the wheel every time.

The Goal

AnyModal is built with the following objectives in mind:

Reduce Boilerplate Code

Combining modalities like images or audio with LLMs typically involves repetitive steps—preprocessing, encoding, tokenizing, and integrating. AnyModal minimizes this boilerplate by providing reusable modules for common tasks, letting developers focus on building smarter systems faster.

Enable Seamless Integration

Whether you're working with images using a Vision Transformer (ViT) or audio spectrograms, AnyModal offers plug-and-play components that simplify the integration process. This makes it easy to handle multiple data types within a single framework.

Encourage Experimentation and Customization

AnyModal supports rapid prototyping while offering the flexibility to customize components like feature encoders, projection layers, and tokenizers. It’s versatile enough for both quick experiments and production-level deployments.

Example Usage: Integrating Images with LLMs

Here’s a detailed example of how AnyModal simplifies the integration of image data into LLMs:

1. Install Dependencies

pip install torch transformers datasets torchvision tqdm

2. Initialize Vision Components

from transformers import ViTImageProcessor, ViTForImageClassification

# Load a pre-trained Vision Transformer
processor = ViTImageProcessor.from_pretrained('google/vit-base-patch16-224')
vision_model = ViTForImageClassification.from_pretrained('google/vit-base-patch16-224')

# Define a Vision Encoder to extract feature embeddings
from vision import VisionEncoder
vision_encoder = VisionEncoder(vision_model)

3. Initialize Tokenizer and LLM

from transformers import AutoTokenizer, AutoModelForCausalLM

# Load a pre-trained LLM and its tokenizer
llm_tokenizer = AutoTokenizer.from_pretrained("gpt2")
llm_model = AutoModelForCausalLM.from_pretrained("gpt2")

4. Define a Projection Layer

from vision import Projector

# Create a projection layer to map vision embeddings to LLM token space
vision_tokenizer = Projector(
    in_features=vision_model.config.hidden_size, 
    out_features=768
)

5. Combine Everything with AnyModal

from anymodal import MultiModalModel

# Build the multimodal model
multimodal_model = MultiModalModel(
    input_processor=None,
    input_encoder=vision_encoder,
    input_tokenizer=vision_tokenizer,
    language_tokenizer=llm_tokenizer,
    language_model=llm_model,
    input_start_token='<|imstart|>',
    input_end_token='<|imend|>',
    prompt_text="Describe this image: "
)

6. Training and Inference

Training involves processing batches of image-text pairs and optimizing the model:

from torch.utils.data import DataLoader
from datasets import load_dataset

# Load a sample dataset
dataset = load_dataset("image_caption_dataset", split="train")

# Prepare DataLoader
train_loader = DataLoader(dataset, batch_size=2, shuffle=True)

# Training Loop
optimizer = torch.optim.AdamW(multimodal_model.parameters(), lr=3e-4)

for epoch in range(10):
    for batch in train_loader:
        optimizer.zero_grad()
        logits, loss = multimodal_model(batch)
        loss.backward()
        optimizer.step()

# Generate captions
sample_input = dataset[0]['image']
generated_caption = multimodal_model.generate(sample_input, max_new_tokens=30)
print("Generated Caption:", generated_caption)

Current Status

AnyModal is currently in its early stages, with the latest version supporting tasks like:

LaTeX OCR
Chest X-Ray Captioning (in progress)
Image Captioning

Future planned features include support for visual question answering and audio captioning.

As the framework evolves, I’m focusing on expanding its functionality, refining the codebase, and addressing community feedback to move towards a stable release.