DEV Community: NITHESH SARAVANAN

Gemma 4 Runs on a Raspberry Pi. Let That Sink In.

NITHESH SARAVANAN — Sat, 23 May 2026 18:52:26 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

I've been thinking about AI wrong for the past two years.

Not completely wrong. But there's an assumption I'd quietly accepted without realizing it — that serious AI models require serious hardware. That if you wanted something capable enough to reason, handle images, work through multi-step problems, you needed a cloud API, or at minimum a machine with a real GPU. That the tradeoff between capability and accessibility was fixed: more of one meant less of the other.

Gemma 4 broke that assumption for me. And the thing that broke it wasn't a benchmark number or a blog post. It was one sentence buried in the release notes:

The E2B model runs on a Raspberry Pi 5.

What Gemma 4 Actually Is

Google DeepMind released Gemma 4 on April 2, 2026, under an Apache 2.0 license — fully open-weight, commercially usable, no strings attached. It's built from the same research as Gemini 3, which is a meaningful statement: this isn't Google's B-team effort. It's frontier-level research packaged for the open ecosystem.

The family ships as four distinct variants, each targeting a different tier of hardware:

Model	Architecture	Active Params	Target Hardware
E2B	PLE (edge)	~2.3B	Raspberry Pi, smartphones
E4B	PLE (edge)	~4.5B	Mobile devices, laptops
26B A4B	MoE (8 of 128 experts)	~4B active	Consumer GPU
31B	Dense	30.7B	Workstation / multi-GPU

Every single one of them is multimodal from the ground up — text, images, video. The smaller models also handle audio natively. Context window is 128K for the edge models and 256K for the larger ones. All support function calling, multi-step reasoning, and configurable thinking modes.

That's the table stakes. Here's what's actually interesting.

The Part That Stopped Me

The E2B model runs in approximately 1.5 GB of RAM at INT4 quantization.

A Raspberry Pi 5 with 8 GB of RAM can run it. Google published numbers confirming this — it's not theoretical, it's a tested deployment target.

I keep coming back to what that actually means. A Raspberry Pi 5 costs around $80. It's a credit-card-sized single-board computer. And it can now run a multimodal AI model that handles text, images, and audio, with a 128K context window, with reasoning capabilities, offline, with no API calls, no cloud dependency, no subscription.

For the past two years, "run AI locally" has been something that required either a powerful laptop or a desktop with a dedicated GPU. The conversation around local AI models has largely been for people with the hardware to run 7B+ parameter models comfortably. E2B changes who that conversation is for.

Why This Is a Bigger Deal Than the Benchmarks

I want to be honest about something: the benchmarks for Gemma 4 are genuinely impressive, but I don't think they're the most important part of this release.

The 31B model sits at #3 on Arena AI's open model leaderboard (ELO 1452 as of release), scores 89.2% on AIME 2026, and hits 80% on LiveCodeBench. Those are strong numbers that hold up against Qwen 3.5 and Llama 4 Scout in most categories.

But benchmark performance is something you read and nod at. The Raspberry Pi deployment is something that changes what you can build.

Think about the categories of projects that become possible when a capable multimodal model can run locally on $80 hardware:

Privacy-first applications. Medical data, personal journals, private documents — things you'd never send to a cloud API. A model that runs entirely on your own device means sensitive data never leaves it.

Offline-first tooling. Field work, remote locations, environments with unreliable connectivity. A capable AI model that works without internet is a different category of useful.

Embedded systems. NVIDIA Jetson devices, edge computing nodes, IoT hardware with more capability than a microcontroller. Gemma 4 E2B was specifically built with these targets in mind.

Projects for students and developers in contexts where cloud API costs are a real barrier. $80 hardware is still not nothing. But it's a different category of accessible than "pay per token forever."

How the Four Variants Actually Fit Together

After spending time with the model card and the community documentation, here's how I'd think about which variant to reach for:

E2B — for genuine edge deployment. Raspberry Pi, smartphones, embedded hardware. If your constraint is RAM and you need offline capability, this is the one. Don't reach for it if you're on a laptop — you're unnecessarily limiting yourself.

E4B — the sweet spot for most personal projects and local laptop experimentation. Fits in roughly 5 GB RAM. Strong enough for real tasks, accessible enough to run comfortably on most modern machines.

26B A4B (MoE) — deceptively efficient. It has 26 billion total parameters but only activates around 4 billion per token pass thanks to Mixture-of-Experts routing. If you have a consumer GPU with 8-12 GB VRAM, this is where serious capability starts without the full cost of running a dense model. The MoE architecture means inference is faster than the parameter count suggests.

31B Dense — for when you need the ceiling. All 30.7 billion parameters active on every pass. Highest benchmark scores, highest hardware requirements. Realistically a multi-GPU or high-VRAM workstation setup.

One thing I appreciate about how Google structured this: these aren't just size variants of the same model. The E2B and E4B use Per-Layer Embeddings rather than traditional MoE routing — it's a genuinely different architectural approach to making models efficient at the edge, not just a quantized-down version of the larger model.

What I'm Actually Thinking About Building

I'll be honest: my hardware situation right now is a mid-range laptop and a Raspberry Pi 4 I've had sitting around for two years mostly running Pi-hole. Not exactly a GPU workstation.

Before Gemma 4, my options for local AI were limited enough that I mostly reached for APIs. After reading through the E2B specs, I'm genuinely reconsidering that default.

What I want to explore: a local document analysis tool that processes my own notes and files without any of that data leaving my machine. The 128K context window on E2B means I could feed in reasonably sized documents. The multimodal support means I could include images and diagrams. The offline capability means it works whether I'm connected or not.

That's not a groundbreaking project. But it's exactly the kind of project I'd been mentally filing under "not possible without a paid API" — and Gemma 4 moves it into the "actually try it this weekend" category.

The Honest Caveat

The E2B running on a Raspberry Pi is real, but context matters: Google tested with INT4 quantization, which trades some precision for memory efficiency. Performance at INT4 is lower than at higher precision levels. For tasks requiring nuanced reasoning or precise outputs, you'll notice the difference.

The 31B dense model's hardware requirements are also substantial — up to 19 GB RAM in some configurations. "Runs on consumer hardware" is true for the family, but not uniformly true across all variants.

And the MoE architecture of the 26B, while efficient, behaves differently in practice than a dense model of equivalent active parameter count. Worth benchmarking for your specific use case rather than assuming the numbers translate directly.

Why Open-Weight Matters Here

Gemma 4 ships under Apache 2.0. That's not just a licensing detail — it's what makes the edge deployment story meaningful for the long term.

A proprietary model that runs locally is still a dependency on the vendor's continued goodwill, roadmap, and pricing decisions. An Apache 2.0 model is something you can fork, fine-tune, redistribute, and build on without those constraints. The 100,000+ community variants already built on earlier Gemma models exist because the license made that experimentation possible.

For developers building on top of Gemma 4 — fine-tuning it for a specific domain, integrating it into a product, deploying it at the edge — the license is as important as the capability.

Where I Land

I started this thinking about Gemma 4 primarily as another open model release in a busy year of open model releases. I'm ending it thinking about it as something slightly different: a signal that the capability-accessibility tradeoff in AI is more flexible than I'd assumed.

Running a capable multimodal model with a 128K context window offline on an $80 single-board computer is not the ceiling of what Gemma 4 can do. It's the floor.

That reframe matters for what I think about building next.

Wrote this after going through the Gemma 4 model card, release blog, and community documentation. To get started: Gemma 4 on Hugging Face, Ollama setup guide, or the official Google AI docs.

Google Antigravity 2.0: The End of the IDE Era (And What Comes Next)

NITHESH SARAVANAN — Sat, 23 May 2026 18:41:58 +0000

This is a submission for the Google I/O Writing Challenge

I'll be upfront about something: I've been burned by AI coding tool hype before.

Over the past couple of years, I've tried most of them — Copilot, Cursor, a few others. And my honest experience is that they're useful right up until they aren't. They suggest something plausible-looking, I accept it, and then twenty minutes later I'm digging through the mess they made while I wasn't paying close enough attention. I still end up fixing things manually. The "AI handles it" promise always seems to quietly expire somewhere in the middle.

So when Google I/O 2026 rolled around and the keynote was wall-to-wall AI announcements, I watched with that specific kind of developer skepticism you develop after a few too many over-promised demos.

But then something made me stop scrolling.

The Demo I Wasn't Expecting

Google Director of Software Engineering Varun Mohan stood on the I/O stage and, using Antigravity 2.0's parallel agent system, built a working operating system core from scratch — live. Total compute cost: under $1,000. Then, on top of that OS, he ran a Doom clone.

I sat with that for a moment.

Not because I think I'll be building operating systems with AI agents next week. But because it reframed something for me. The tools I'd been frustrated with were all trying to assist me while I coded. This was something else entirely — agents executing in parallel, autonomously, producing something that would have taken a team of engineers weeks.

Whether that's ready for everyday use or not, the direction it points in is hard to ignore. And the more I looked at what Google actually shipped alongside that demo, the more I think Antigravity 2.0 deserves a more careful look than the usual I/O hype cycle gets.

What Antigravity 2.0 Actually Is (And What It Isn't)

The original Antigravity launched in November 2025 as, essentially, Google's answer to Cursor. An AI-powered IDE. Useful, but not something that changed how I thought about development.

Version 2.0 is different in a way that took me a while to articulate. It's not trying to be a better editor. It's trying to replace the editor as the central surface of development altogether.

The 2.0 release ships as five distinct pieces:

1. The Standalone Desktop App

The new desktop app isn't a code editor with AI bolted on. It's built around managing parallel agents — you describe what you want, multiple specialized subagents spin up concurrently, and the app is your dashboard for what they're doing.

The conceptual shift here is real. Every editor I've used puts me at the center — my cursor, my decisions at every line. Antigravity 2.0 puts the agent workflow at the center and positions me as the person reviewing and directing, not typing.

I'm genuinely not sure how I feel about that yet. But it's a different bet than anyone else is making.

2. The Antigravity CLI (`agy`)

Built in Go, brings the full agent harness to your terminal. If you live in the command line — which I do more and more — this matters. It has built-in sandboxing, credential masking, and hardened Git policies baked into the foundation, not added as an afterthought.

3. The Antigravity SDK

This is for teams who want to deploy custom agents on their own infrastructure rather than routing everything through Google's cloud. For anyone with compliance requirements or data concerns, this is what makes the platform actually usable in a professional context.

4. Managed Agents in the Gemini API

One API call. Full agent. Sandboxed Linux environment. Persistent state. More on this in a moment — it's the part I actually tested.

5. The Gemini Enterprise Agent Platform

Managed deployment path for large organizations inside Google Cloud. More restricted access right now, but the direction is clear.

I Actually Tried It (Here's What I Found)

My instinct after any big I/O announcement is to go read the actual docs rather than the blog posts. So that's what I did.

The Managed Agents quickstart is genuinely simple. Here's the call that provisions a full agent environment:

from google import genai

client = genai.Client()

interaction = client.interactions.create(
    agent="antigravity-preview-05-2026",
    environment="remote",
    input="Write a Python script that generates the first 20 Fibonacci numbers and saves them to fibonacci.txt."
)

print(interaction.output_text)

That single call provisions a fresh Linux sandbox, loads Gemini 3.5 Flash, equips the agent with web search, code execution, and file management — and then runs the whole thing autonomously.

What I kept thinking about as I read through it: the setup I used to have to do manually to get anywhere close to this — provisioning containers, wiring up tool access, managing execution state — was genuinely hours of work before I could even start on the actual problem. This collapses that completely.

The part that actually surprised me was multi-turn session continuity:

# Pick up exactly where the last call left off
interaction2 = client.interactions.create(
    agent="antigravity-preview-05-2026",
    previous_interaction_id=interaction.id,
    environment=interaction.environment_id,
    input="Now plot the Fibonacci sequence as a line chart and save it as chart.png."
)

Same sandbox. Same file system. Same state. Just pass the ID. No serialization, no manual context management.

That's the thing I'd been doing manually for months in my own projects — carefully threading state between agent calls so nothing got lost. Seeing it handled by passing a single ID was a quiet "oh" moment.

The honest caveats though, because there are real ones: this is in preview. The only supported base agent is antigravity-preview-05-2026. There's no agent versioning or rollback yet. Subagent nesting isn't supported. The schema may still change. I wouldn't build production-critical workflows on this today — but as a signal of where the API is heading, it's concrete enough to take seriously.

The Idea Behind It All That Most Coverage Is Missing

Here's what I keep coming back to when I think about Antigravity 2.0.

Every AI coding tool I've used — Cursor, Copilot, even Antigravity 1.0 — made the same underlying assumption: AI should live inside the editor. The editor is where developers work, so meet them there.

Antigravity 2.0 is built on a completely different assumption: the editor itself is the wrong primitive for the agentic era.

Think about what an IDE actually is. It's a surface optimized for a human to produce text at human speed. Every feature — syntax highlighting, file trees, the cursor — exists to support you doing the writing.

But if agents can write, test, and refactor code faster than you can read it, you don't need a writing surface anymore. You need something more like a workflow management dashboard — something that tells you what's running, what's done, what needs your input.

That's what the Antigravity 2.0 desktop app is trying to be.

I find this genuinely interesting to think about, even while holding it somewhat skeptically. The editor has been the central tool of software development for four decades. That's a long time for something to calcify into "just how things work." The question of whether it's actually the right abstraction for AI-assisted development is worth asking out loud.

Where I'm Still Not Convinced

I want to be fair here, because I've been in enough hype cycles to know that interesting architecture doesn't automatically mean good outcomes.

Agent reliability is still the hard problem. My frustration with current AI coding tools is precisely that they make plausible-looking mistakes, and I catch them too late. Parallel subagents executing in the background amplifies that risk — one wrong assumption by one agent, built upon by three others, and you have a mess that's much harder to unwind than a single bad autocomplete suggestion. The sandboxing and Git policies help, but they're guardrails around execution, not guarantees of correctness.

The pricing signals who this is really for. The new AI Ultra plan is $100/month for 5x higher usage limits. That's an enterprise line item. The free and low-cost tiers that independent developers and students typically use to build ecosystem familiarity around a platform are not the story here. Google is making a deliberate choice to prioritize enterprise adoption, and that's worth naming explicitly.

Gemini CLI is being retired for consumer users. This is the consolidation that bothers me most personally. A lightweight, free CLI path is being replaced by Antigravity — which costs money. If you're not on a paid plan, your path to the agent harness is the raw API. That's a real narrowing of access.

"Vibe coding" is a phrase I'm suspicious of. It shows up in the Google AI Studio announcement — "native Kotlin support to vibe code Android apps." I understand what they mean. But "vibe coding" is language that frames effortlessness as the goal, when for a lot of us, understanding what our code does is the goal. The complexity doesn't disappear just because the interface hides it. And for someone still building their fundamentals, that gap between "it works" and "I understand why it works" matters a lot.

What's Actually Different Starting This Week

Setting aside the bigger questions, here's what concretely changed at I/O for different kinds of developers:

If you use the Gemini API: Managed Agents is worth exploring now. The quickstart is genuinely accessible and you can have something running in under 15 minutes. The friction reduction on multi-step agent workflows is real.

If you work on Android: The Android CLI is now stable, and the open-sourced Android skills give LLMs verified scaffolding for complex migrations — Jetpack Compose, Jetpack Navigation 3 — rather than the hallucinated patterns that have burned people before. The migration agent for React Native or iOS codebases to native Kotlin is notable if you're carrying that kind of technical debt.

If you work on the web: WebMCP is the slow-burn announcement. A proposed open standard for browser-based AI agents to interact with JavaScript functions and HTML forms is infrastructure-level stuff — currently in origin trial in Chrome 149. Watch this one over the next year.

If you run or work on a team: The SDK and Enterprise Agent Platform are what make this usable in real organizational contexts. The security primitives aren't bolted on.

Where I Land

I came into Google I/O 2026 skeptical about AI development tooling, and I'm leaving it with that skepticism mostly intact — but pointed at more specific things.

The architecture of Antigravity 2.0 is genuinely interesting. The Managed Agents API simplifies something I've been doing manually for a long time. The thesis — that the editor is a legacy abstraction — is a real idea worth taking seriously, not just keynote positioning.

But the pricing, the accessibility concerns, and the unresolved question of agent reliability are all real. Interesting architecture and practical daily usefulness are different things, and only one of them matters when you're trying to ship.

What I'd say is: try the Managed Agents API if you use Gemini. Read the Antigravity 2.0 release notes carefully rather than the blog posts. And if the IDE-as-legacy-abstraction thesis turns out to be right, you'll want to have been paying attention when this shipped.

The direction is clear. Whether the execution catches up to it is the question the rest of 2026 will answer.

Wrote this after spending an evening with the Google I/O 2026 developer keynote and the actual Gemini API docs. Try Managed Agents at the official quickstart and explore Antigravity 2.0 at antigravity.google.

DEV Community: NITHESH SARAVANAN

Gemma 4 Runs on a Raspberry Pi. Let That Sink In.

What Gemma 4 Actually Is

The Part That Stopped Me

Why This Is a Bigger Deal Than the Benchmarks

How the Four Variants Actually Fit Together

What I'm Actually Thinking About Building

The Honest Caveat

Why Open-Weight Matters Here

Where I Land

Google Antigravity 2.0: The End of the IDE Era (And What Comes Next)

The Demo I Wasn't Expecting

What Antigravity 2.0 Actually Is (And What It Isn't)

1. The Standalone Desktop App

2. The Antigravity CLI (agy)

3. The Antigravity SDK

4. Managed Agents in the Gemini API

5. The Gemini Enterprise Agent Platform

I Actually Tried It (Here's What I Found)

The Idea Behind It All That Most Coverage Is Missing

Where I'm Still Not Convinced

What's Actually Different Starting This Week

Where I Land

2. The Antigravity CLI (`agy`)