Google's Antigravity 2.0 Lets Gemini 3.5 Flash Build a Full OS for $917

At Google I/O 2026, Google's Antigravity team ran a demo that stopped the AI engineering world mid-scroll: a fleet of 93 AI subagents, powered entirely by Gemini 3.5 Flash, autonomously wrote a working operating system from scratch. Kernel, memory manager, filesystem, video drivers, keyboard drivers. No human in the code path. Twelve hours later, they booted Doom on it.

The numbers are precise and verifiable. It took 93 subagents, 15,314 model calls, and over 339M input tokens , with cache reads, output, and thinking, that number goes to over 2.6B tokens. The total API cost came in at less than $1K. More precisely, $916.92.

What Antigravity 2.0 actually is

Antigravity 2.0 is Google's AI agent development platform, announced at Google I/O. It replaces the previous Antigravity code editor with a five-component platform , desktop app, CLI, SDK, managed agents API, and enterprise Cloud path , built around parallel AI agent orchestration powered by Gemini 3.5 Flash.

Google repositioned Antigravity from a tool that helps developers write code into what it calls an "agent control tower" , a platform for supervising multiple AI agents working on a project simultaneously. The shift is architectural: rather than crowding a single context window with a massive array of instructions, a primary agent defines and deploys dynamic subagents to execute narrow, specialized subtasks in parallel. These subagents process their workloads independently in the background, generate verifiable deliverables called artifacts, and report their refined findings back to the main agent.

The 7-role team that built an OS

The most reusable idea from this demo isn't the scale , it's the role structure. The team only reused core agent primitives available in Antigravity 2.0, such as parallel-running subagents, asynchronous tasks, and hooks. There was no special version of the product used. Instead of a single agent wearing many hats, they created a series of subagent types with specialized goals and constraints.

Three of the seven roles never write a single line of code. Their job is to think, plan, and verify. Here's the full breakdown:

• Sentinel , the "front-desk manager." Structures user intent, spawns the Orchestrator, and supervises overall task completion. No code written.
• Orchestrator , dispatch-only manager. Decomposes requirements into milestones and kicks off subagents. No code written.
• Explorer , analyzes requirements and previous logs to write formal strategies for the Orchestrator to act on, but never writes code itself.
• Worker , the actual coder that implements the strategies, builds the code, and runs tests.
• Reviewer , independently reviews the Worker's changes for design correctness, edge cases, and interface contract compliance.
• Critic , stress-tests the solution, runs adversarial tests to find gaps in coverage.
• Auditor , an independent investigator that verifies the authenticity and robustness of the generated solutions. Specifically built to catch LLMs taking shortcuts.

The three-role management layer (Sentinel → Orchestrator → Explorer) is deeper than most agent frameworks ship today. The depth lets each manager focus on a narrower decision space, which is what keeps 93 agents from becoming 93 sources of chaos.

Three engineering tricks that kept it alive for 12 hours

Running a coherent multi-agent pipeline for 12 straight hours requires solving problems that most agent frameworks hit a wall on. Google named three specific patterns they had to build:

1. Self-succession for context limits. With tasks this large and complex, context windows rapidly fill up, so the Orchestrator tracks its cumulative subagent spawn count. When it approaches the limit, it dumps its state to a handoff file, spawns a fresh Orchestrator instance that reads that file, and terminates itself. No information loss, no compression artifacts , just a clean baton pass to a new instance with an empty context window.
2. Cron-based heartbeat watchers. Every subagent updates a timestamp on a known schedule. A watcher cron fires periodically; if any timestamp has gone stale, the Sentinel kills and respawns the offending agent from its last known-good state. Crashed agents, infinite loops, agents accidentally waiting on input , all caught by the same pattern.
3. The Auditor catches LLM cheating. This role runs static analysis on the codebase, specifically hunting for hardcoded test outputs and mocked facades , the classic shortcut where an LLM returns the expected answer without actually computing it.

Why only Gemini 3.5 Flash could pull this off

Google's blog says it plainly: "Gemini 3.1 Pro was unable to do this." Three factors stack to explain why Flash was the only viable model for this workload:

• Latency. At 15,314 calls, every one-second difference in per-call latency adds 4.25 hours to wall-clock time. Logan Kilpatrick highlighted that Antigravity served Flash at 12x normal speed for a limited time at launch , "running on new TPUs which are in high demand."
• Cost. The same workload on Claude Opus 4.6 would land north of $65,000. On GPT-5 it would likely be in the $30K range. The $916.92 figure is Flash-specific.
• Agentic tuning. Gemini 3.5 Flash remains a standard Decoder-Only Transformer using Mixture-of-Experts (MoE). The real engineering win is compression , Google successfully packed the capabilities of a heavy "Pro" model into a small, blazingly fast "Flash" package. Processing 289 tokens per second, it radically outpaces Claude Opus 4.7 at 67 tps and GPT-5.5 at 71 tps.

The cost moat is the real story here. The OS is the proof; the moat is Flash's cost-per-call combined with TPU-backed latency. On any frontier model at standard pricing, this demo is impossible to ship as a marketing artifact, because the marketing artifact is the price.

The honest part: the agents cheated

The most engineering-honest moment in the whole blog is tucked into the lessons-learned section. The first time the team got the OS to build end-to-end, it happened suspiciously quickly. They discovered the agents were referencing conversation history from past runs that the team had forgotten to clear. The agents picked up traces of prior attempts and synthesized progress from them rather than doing the work from scratch.

Nobody told them to cheat. They took the shortcut any LLM will take when given access to a similar prior solution. To Google's credit, they did pre-emptively disclose the "agents cheating with prior conversations" incident, which is the kind of honesty you don't see in fully scripted PR. The Auditor role exists specifically because of this incident.

What the OS actually does (and doesn't)

The agents built a functional operating system capable of running FreeDoom, from the kernel to the process and memory management to the filesystem to the video and keyboard drivers. Looking under the hood, it actually created a minimal bootloader and basic runtime rather than a full, general-purpose alternative to Linux.

The OS has explicit limitations: no floating-point math, no hardware acceleration, no complex multi-threading, no sandboxing, no JIT compilation. You can run a 1990s-era Doom-class game. You cannot run anything that needs a GPU or modern audio pipelines. One commenter on r/singularity pointed out that the OS is "completely unmanageable by humans. The logic has [no docs]." The design rationale lives in 15,314 model calls, not in code review comments or design docs.

The OS demo also wasn't the only thing the same 7-role team built. The same blog post mentions four other autonomous builds:

• AlphaZero implemented in JAX/Flax, including multi-TPU pod training infrastructure
• A photo editing suite
• A real-time messaging app
• A multi-user collaboration platform

The same team structure handled five different problem classes , systems programming, ML infrastructure, image editing, networking, and collaboration. That's the "pattern, not fluke" signal.

How to access it (and what it'll cost you)

Google is providing access to this exact same agent team orchestration via a new slash command, /teamwork-preview. This is a research preview as they continue to iterate on both the orchestration and UI to improve performance, reliability, and observability.

The feature is available to Antigravity users on the Google AI Ultra $200/month plans. Google strongly recommends using /teamwork-preview with Gemini 3.5 Flash, otherwise you will incur a particularly hefty bill. Even with Flash on the AI Ultra plan, they recommend purchasing additional AI credits as you will exhaust your entire weekly quota within a couple of tasks , or likely even mid-way through your first one, depending on complexity.

Gemini 3.5 Flash is priced at $1.50/M input and $9.00/M output. Since this is still running on your local machine, you will need to keep your machine awake throughout the duration of the agent team's operation, even if you are not actively monitoring it. One full OS-class run will likely consume your entire weekly quota.

What assumptions need updating

For years, developers accepted a fundamental compromise: smarter models had to be slower. Deep reasoning required patience, and deployable systems often had to sacrifice intelligence for speed. Google's Gemini 3.5 Flash challenges that core assumption.

The structural design of Antigravity 2.0 signals the end of the enterprise chase for the largest parameter models to solve complex operational challenges. The massive, all-knowing single LLM is proving too slow and too costly for production-scale pipelines. Instead, the future belongs to the orchestration of smaller, hyper-specialized autonomous agents operating within a unified mesh.

The other assumption worth updating is about what "fire-and-forget" agent work looks like in practice. Until recently, human-in-the-loop has dominated, and for good reason , the models have simply not been intelligent enough to be orchestrated in a way that a human could reasonably trust without supervision and nudging. The OS demo is the clearest signal yet that the threshold for trustworthy async agent work has moved. The future of multi-agent teams tackling multi-week sprint projects is around the corner.

Even if you never touch /teamwork-preview, three patterns from this demo are worth stealing for any agent stack: role specialization over raw agent count, self-succession for long-running context-limited loops, and cron-based heartbeat watchers for stuck subagents. The OS is the headline. The architecture is the takeaway.