Google DeepMind just released a browser that generates entire websites from a single sentence. You type “a guide to watering my cheese plant,” and Gemini 3.1 Flash-Lite writes a complete page — navigation, layout, content — in under two seconds. No server. No pre-built HTML. The page is born the moment you ask for it.

The Flash-Lite Browser is a striking demo. But it also exposes a structural gap in how we think about agent interfaces. The industry is converging on an architecture — CLI for agents, protocols for communication, generated GUI for humans — but this three-layer stack is missing something critical.

The Three-Layer Interface Stack

A pattern is forming across the agent ecosystem. It looks like this:

Bottom layer: CLI is the agent runtime. Agents operate through text commands — structured input, structured output, composable pipelines. This is their native language. Claude Code, GitHub Copilot CLI, and every MCP-connected agent speak CLI first.

Middle layer: Protocols connect agents to the world. MCP connects agents to tools. AG-UI connects agents to frontend interfaces. A2UI lets agents describe UI components declaratively. A protocol triangle is taking shape.

Surface layer: GUI becomes what AI generates for humans. Flash-Lite Browser is the extreme case — the entire page is AI-generated. But even conventional agent UIs (chat interfaces, dashboards, reports) are increasingly produced by models rather than designed by humans.

This three-layer view is useful. It explains why terminal usage among professional developers jumped from 62% to 78% in two years (Stack Overflow Developer Survey). It explains why Claude Code reached $1B ARR within months of launch. And it explains why Google is experimenting with browsers that generate rather than fetch.

But it describes architecture. It says nothing about dynamics.

The Missing Fourth Layer: Selection Pressure

Here is the question the three-layer model does not answer: when a hundred agents can all generate a UI, which one should you trust?

Flash-Lite Browser generates a plant care page in 1.93 seconds. Impressive. But as The Decoder noted, “results are not stable — content quickly drifts off-topic.” The same query produces different layouts. Navigation leads to inconsistent pages. The content is plausible but unreliable.

This is not a model quality problem that will be solved by the next generation of LLMs. It is a selection problem. When interfaces are generated rather than designed, you need a mechanism to evaluate which generation approach produces better outcomes — and to let bad approaches fade away.

In biology, that mechanism is natural selection. In software, we have been building its equivalent.

The Rotifer Protocol introduces a competitive evaluation layer where modular capabilities — called Genes — are scored by a multiplicative fitness function:

$$
F(g) = frac{S_r cdot log(1 + C_{util}) cdot (1 + R_{rob})}{L cdot R_{cost}}
$$

Success rate, community utility, robustness, latency, cost — all measured, all weighted, all used to rank competing implementations. Genes that score well propagate. Genes that score poorly retire. The selection pressure is quantified and continuous.

This is the missing fourth layer: evolution infrastructure. Not just connecting agents to tools (protocols do that), but deciding which tools survive.

Protocols Connect. Evolution Selects.

MCP is a connectivity standard. It tells an agent how to discover and invoke a tool. But it says nothing about whether the tool is any good.

Consider an agent choosing between three MCP-connected tools that all claim to generate plant care guides. MCP ensures the agent can call any of them. But which one produces accurate watering schedules? Which one formats content clearly? Which one hallucinates less?

Without a fitness layer, the agent has no signal. It picks randomly, or picks the first one it finds, or picks the one with the most downloads — none of which correlate reliably with quality.

The Arena provides that signal. Competing Genes run against standardized benchmarks. Their fitness scores are public. Agents can query the registry and select the highest-ranked Gene for a given task. The selection is data-driven, not arbitrary.

This pattern — protocol for discovery, evolution for quality — is the full stack.

The Reliability Problem Reframed

The criticism of Flash-Lite Browser is that results are unstable. Every render differs. Same query, different layout.

But instability is not inherent to AI-generated interfaces. It is a symptom of missing selection pressure. When there is no mechanism to evaluate which generation approach works better, every approach is equally likely to be used — including bad ones.

Imagine a world where UI generation Genes compete in an Arena. A Gene that produces consistent, readable plant care pages scores higher than one that drifts off-topic. Over time, the drift-prone approach is selected against. The ecosystem converges toward reliability — not because someone manually debugged each page, but because the fitness function rewards consistency.

This is how biological systems solve the reliability problem. Not through top-down design, but through bottom-up selection.

Four Layers, Not Three

The complete agent interface stack is not three layers. It is four:

The first three layers describe what agents can do. The fourth layer determines which agents do it well.

Google’s Flash-Lite Browser is a preview of the GUI layer’s future. MCP is establishing the protocol layer. CLI has been the agent runtime for over a year. But without evolution infrastructure, the stack is incomplete — beautiful demos that produce unreliable results.

The interface revolution is real. The question is whether we build the selection layer before or after unreliable agent outputs erode user trust.

We think before.

rotifer.dev

Every year, healthcare organizations spend billions on compliance.
Auditors review policies. Security teams run vulnerability scans.
Certifications get renewed. And yet the actual code running on
production healthcare systems, the code that handles your medical
records, your Social Security Number, your vaccination history,
remains largely unexamined.

We decided to examine it.

Over the past several months, we built a static analysis engine
that reads healthcare source code the way a compliance auditor
would, mapping code patterns directly to specific HIPAA sections,
GDPR articles, SOC 2 criteria, and India’s DPDPA requirements.
Then we pointed it at 3,000 public healthcare repositories spanning
9 programming languages and 4 continents.

13,427 confirmed violations. 43.6% of repositories affected.

The organizations involved are not small or obscure. They include
the US Centers for Disease Control, the US Department of Veterans
Affairs, NHS England, Google, and some of the most widely deployed
open-source healthcare platforms in the world.

The gap nobody is closing

Here is the compliance problem nobody talks about.

Security scanners like Snyk and Semgrep find known vulnerabilities,
outdated dependencies, common attack patterns, CVEs. Compliance
audits check whether policies exist, whether a Business Associate
Agreement is signed, whether an access control policy is documented.

Neither examines whether the application code actually implements
the safeguards that regulations require.

A hospital can have a perfect HIPAA policy document and a clean
Snyk scan while its billing export writes every patient’s Social
Security Number to a plaintext CSV file on the server filesystem.
That is not a hypothetical. That is OpenEMR, the most widely
deployed open-source EMR with over 100,000 installations worldwide.

This is the gap. And it is systemic.

What we actually found

The VA knew and suppressed it

The US Department of Veterans Affairs notification-api handles SMS,
email, and push notifications for 9 million veterans deployed to
AWS GovCloud.

One Lambda function disables TLS certificate verification with
verify=False. Alongside it sits an explicit # nosec annotation,
a security scanner suppression comment used by developers to silence
warnings they don’t want to fix.

The development team was aware this was a security issue. They
suppressed the warning and deployed to production anyway. Veteran
phone numbers and SMS content are logged in plaintext. All affected
functions deploy across dev, staging, perf, and prod environments
via GitHub Actions.

NHS England queries 58 million patient records with TLS disabled

OpenSAFELY is a secure analytics platform for NHS England
electronic health records. The cohort-extractor tool queries
patient data from approximately 58 million NHS patients.

TLS certificate verification is unconditionally disabled for its
EMIS database connection. Security warnings are globally suppressed.
A TODO comment in the code confirms the developers are aware:

# TODO remove this when certificate verification reinstated

The TODO is still there.

India’s vaccination platform logged Aadhaar numbers to stdout

India’s DIVOC platform powered the national COVID vaccination
certificate system used by hundreds of millions of Indian citizens.

The code serializes the entire certificate request to application
logs, Aadhaar number, name, date of birth, gender, phone number,
home address, for every single certificate created. A separate
analytics consumer prints every Kafka vaccination message to stdout
unconditionally with no feature flag, no log level gate, and no
way to disable it without modifying source code.

Production CoWIN URLs in the Kubernetes deployment configs confirm
this ran on India’s national vaccination infrastructure.

We reported this to CERT-In on March 23, 2026.

OpenEMR writes patient SSNs to plaintext CSV files

OpenEMR’s billing export feature writes patient Social Security
Numbers, names, dates of birth, addresses, and phone numbers to a
plaintext CSV file via fwrite(). Zero encryption. No audit trail.

When we contacted the OpenEMR security team, they confirmed this
is intended functionality, citing HIPAA’s “addressable”
specification as placing the obligation on the deploying
organization.

100,000+ installations. Every one generating unencrypted files
containing the most sensitive category of patient data with no
application-level option to encrypt them.

The finding that should concern everyone most

Of everything we found, one pattern stands out as the most
forward-looking risk.

Across 3,000 repositories, our analysis detected 657 confirmed
instances of patient medical data flowing into AI and machine
learning pipelines without de-identification. This includes CSV
exports fed into model training, inference calls containing
identifiable patient records, and analytics pipelines processing
raw PHI.

Metriport, a funded healthcare API company, sends patient medical
record data to an AI model via Amazon Bedrock. No de-identification
or tokenization is visible before the API call.

This is not a niche finding. As healthcare organizations race to
adopt AI for clinical decision support, triage automation, and
population health analytics, PHI is flowing into these pipelines
at scale. Traditional security scanners were not built to detect
this pattern. Most compliance frameworks have not yet caught up
with it either.

The code is ahead of the regulations. And the data is already
moving.

Why this keeps happening

Compliance failure in our dataset does not correlate with funding,
team size, or institutional credibility. The VA has significant
engineering resources. NHS England runs one of the largest health
data platforms in the world. Google has some of the best security
engineers on the planet.

The correlation is simpler: nobody checked the code.

Not because organizations are negligent. Because the tools and
processes that exist today were not designed to check it. Security
scanners operate at the dependency and vulnerability layer.
Compliance audits operate at the policy and process layer. The
application code layer, where PHI actually moves, where encryption
actually gets implemented or skipped, where logging decisions
actually get made, sits between these two worlds largely unexamined.

That is the gap. And until it gets closed, compliance certifications
will continue to mean less than they should.

What this means for patients

You have no way of knowing whether the healthcare application
handling your data was ever checked at the code level for
compliance. Your provider may have passed a HIPAA audit. Their
software vendor may have a SOC 2 certificate. Neither guarantees
that your Social Security Number is not being written to a plaintext
file somewhere on a server filesystem.

That is not a reason for panic. It is a reason for the industry
to close a gap that has been ignored for too long.

All affected organizations were notified through responsible
disclosure channels prior to publication.

There are two kinds of developers in 2026.

The first kind is paying for every AI request like it’s normal.

The second kind is quietly collecting free quotas, trial credits, OpenAI-compatible endpoints, Gemini access, Groq speed, random hidden gems, and stitching them together into one ridiculous local setup.

This post is for the second kind.

The Real Problem Isn’t “Which Model Is Best?”

The real problem is this:

• One provider gives you speed
• Another gives you free credits
• Another gives you decent coding models
• Another looks promising but isn’t integrated yet
• And your tools? They all want different configs, different keys, and different endpoints

So your stack turns into a graveyard of:

• half-used trial credits
• forgotten API keys
• rate-limited accounts
• browser bookmarks you’ll never open again

So I Built the Map

ProxyPool Hub now includes a Resources Catalog: a dedicated page that tracks free and trial LLM API platforms in one place.

Not just a dumb markdown list.

A real, filterable directory.

You can now browse a curated catalog of providers like:

• OpenRouter
• Google AI Studio
• Groq
• Cerebras
• SambaNova Cloud
• Hyperbolic
• Scaleway Generative APIs
• and more

Each entry includes:

• whether it’s free or trial
• whether ProxyPool Hub already supports it
• representative models
• signup requirements
• quota notes
• compatibility details
• whether it can be preset directly into the proxy

In other words:

it doesn’t just tell you what’s out there — it tells you what you can actually use right now.

This Is Where It Gets Dangerous (In a Good Way)

Because ProxyPool Hub isn’t just a resource browser.

It’s also the thing that lets you use those resources without losing your mind.

1. Free Model Routing

The new free model flow lets lightweight requests route to free providers automatically.

So instead of burning paid credits for every tiny task, you can push fast or low-cost workloads toward free-tier resources.

That means:

• quick coding questions → free routes
• lightweight model tasks → free routes
• expensive reasoning jobs → your better accounts or keys

It’s not just cheaper.

It changes your whole cost model.

2. Load Balancing Across API Keys

Most people use API keys like this:

1. Add one key
2. Use it until it breaks
3. Panic
4. Switch manually

ProxyPool Hub does the opposite.

It watches all your available keys and picks the one with the fewest requests first.

That’s simple load balancing, but the practical effect is huge:

• your keys last longer
• rate limits hit later
• traffic spreads out automatically
• failures become much less noticeable

It feels less like “using an API key”

and more like running your own tiny inference mesh on localhost.

3. Pooling Accounts and Providers Like a Greedy Goblin

This is the part I like the most.

You don’t have to marry one provider.

You can build a setup like this:

• OpenRouter for rotating free models
• Google AI Studio for Gemini access
• Groq when you want stupid-fast responses
• Cerebras when you want extra OpenAI-compatible capacity
• SambaNova / Hyperbolic / Scaleway for trial credits
• your own Claude / OpenAI / Azure accounts for the heavy jobs

Then point your tools at one local address.

That’s the whole trick.

Your tools don’t need to know your secret economy.

They just talk to the proxy.

4. The Catalog Is Actually Strategic

The smart part of the Resources Catalog isn’t that it lists providers.

It’s that it classifies them by practical usability:

• supported → already works cleanly with ProxyPool Hub
• presettable → can be slotted in with current patterns
• candidate → promising, but needs extra adapter work
• catalog only → good to know, not worth pretending it’s plug-and-play yet

That’s rare.

Most AI lists are fluff.

This one is operational.

It answers:

“Can I actually use this in my setup today?”

Why This Matters

Because the AI tooling world is getting weirder, not simpler.

Every month, new free endpoints appear.
Every week, quotas change.
Every day, someone discovers another provider with surprise credits and weird limits.

If you don’t organize that chaos, you waste it.

ProxyPool Hub now gives you both sides of the game:

• Discovery — find free/trial opportunities fast
• Execution — route, pool, balance, and survive rate limits

The Vibe

This is no longer just “a proxy for Claude Code and Codex.”

It’s becoming something more interesting:

a local control plane for AI tool traffic.

One place to:

• discover providers
• compare quotas
• pick usable free options
• spread load across keys
• route by app
• preserve paid credits
• keep your CLI tools working even when one provider taps out

Try It

npx proxypool-hub@latest start

Then open:

• http://localhost:8081 → dashboard
• http://localhost:8081/resources/ → free & trial resources catalog

Links

• GitHub: github.com/yiyao-ai/proxypool-hub
• npm: npmjs.com/package/proxypool-hub
• Discord: Join the community

If you’re the kind of developer who keeps a secret stash of trial credits and free endpoints, this might be your new favorite project.

And if you’re not?

Give it a week.

ProxyPool Hub is open-source under AGPL-3.0. Not affiliated with Anthropic, OpenAI, Google, or any listed provider.