How 93 Agents Built an OS in 12 Hours: Antigravity 2.0's Viral Demo Explained (2026)

The demo in 60 seconds

Google’s original tweet (@Google, May 19 2026, 17:29 UTC) put the numbers front and centre:

“We asked our agents to build a working operating system from scratch using @Antigravity 2.0 and Gemini 3.5 Flash.

It took:

⏱️ 12 hours
🤖 93 parallel sub-agents
🔄 15k+ model requests
🧠 2.6B tokens processed
💸 Less than $1K in API credits

To build a functioning OS from scratch.”

The official deep-dive at antigravity.google/blog/google-antigravity-built-an-os fills in the more precise figures: 93 subagents, 15,314 model calls, >339M input tokens, >2.6B total tokens across input plus cache reads plus output plus thinking, $916.92 at API pricing, 12 hours wall-clock, all from a single prompt, all on Gemini 3.5 Flash. The follow-up tweet added the bit that landed hardest with engineers: “The @Antigravity agents wrote every line of code — from the kernel to the process and memory management system. Generated, audited, and tested entirely by an autonomous team of agents.”

Two notes on the numbers before we go further. First, the r/singularity headline that drove most of the secondhand reporting said “Google’s Antigravity 2.0 creates an operating system from scratch using 96 agents in 12 hours”. That thread hit 562 upvotes and 138 comments, and quite a few downstream blog summaries copied the 96. The primary source — Google’s own engineering blog — says 93. We’ll use 93 throughout. Second, the tweet’s “less than $1K” is pre-rounding for impact; the deep-dive’s $916.92 is the actual figure. Use that one when you cite it.

The numbers, decoded

Headline numbers are designed to be sticky. Let’s break them apart so you can tell what they actually represent.

15,314 model calls

Each call is one round-trip request to Gemini 3.5 Flash. Spread over 12 hours that’s about 21 calls per minute, or one every three seconds on average. Across 93 subagents that’s roughly 165 calls per agent over the lifetime of the run — not evenly distributed (Workers and Reviewers dominate, the Orchestrator does less), but the order of magnitude is useful. For comparison, a typical Claude Code session that ships one PR is in the range of 50-200 calls. The OS demo is closer to 75 ordinary developer sessions running in parallel and coordinating their output.

>339M input tokens and >2.6B total

The gap between input tokens (339M) and total tokens (2.6B) is the part most people skim past. It’s the most informative number in the dossier. The 2.6B figure includes input + cache reads + output + thinking. That means roughly 87% of the total token volume is cached prompt prefixes, reasoning trace tokens, and generated output — not fresh input that has to be re-encoded from scratch. The implication: this only works on a model stack that supports aggressive prompt caching. Without cache hits, the cost would be 4-5x higher even at Flash pricing.

Average input per call: 339,000,000 / 15,314 ≈ 22,135 input tokens per call. That fits comfortably under any modern frontier model’s context window. The agents weren’t maxing context; they were running medium-sized contexts in tight loops with heavy cache hits.

$916.92 total cost

The most precise number, and the one Google chose to lead with as “less than $1K.” Divide it out: 2.6B tokens for $916.92 is a blended rate of about $0.35 per million tokens across the whole input/output/cache/thinking mix. That’s the first concrete anchor anyone has for Gemini 3.5 Flash economics — Google has not published per-token pricing in the launch materials, only the rhetorical claim “often at less than half the cost of other frontier models.”

12 hours wall-clock and a single prompt

Twelve hours from one prompt is the line that puts the demo into the “sci-fi” category for most readers. But notice what it implies about parallelism: 15,314 sequential 3-second calls is roughly 12.7 hours of wall-clock if they were single-file. Which means the 93 agents must have been running mostly sequentially-coordinated, not embarrassingly parallel — the orchestration overhead, the review/critic/audit cycles, and the self-succession handoffs ate most of the time-budget savings parallel execution would otherwise have produced. The agents weren’t fanning out to 93 concurrent build jobs. They were taking turns through a structured pipeline.

Why only Gemini 3.5 Flash worked (the cost moat)

Google’s blog says it plainly: “Gemini 3.1 Pro was unable to do this.” It doesn’t fully explain why. Reading between the lines, three factors stack:

1. Latency. At 15,314 calls, every one-second difference in per-call latency adds 4.25 hours to wall-clock. 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.” A Pro-tier model at normal latency wouldn’t fit in 12 hours regardless of cost.
2. Cost. The dossier’s most pointed comment thread, from r/singularity: “Isn’t Opus 4.6 $25/m tokens so 2.6b tokens would be $65k?” The math is correct. 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. On any frontier model at standard pricing, this demo is impossible to ship as a marketing artifact, because the marketing artifact is the price.
3. Agentic tuning. Google’s launch benchmarks for 3.5 Flash specifically highlight agentic and tool-use scores: Terminal-Bench 2.1 76.2%, MCP Atlas 83.6%, GDPval-AA 1656 Elo, CharXiv Reasoning 84.2%. The blog explicitly says Flash is “outperforming Gemini 3.1 Pro on challenging coding and agentic benchmarks.” This isn’t the usual story where the small model does worse than the big model; Flash was specifically optimised for the tool-use loop that this demo lives inside.

So the demo’s real claim is not “we built an OS for $916.” The real claim is “we built a model where you can build an OS for $916.” The OS is the proof; the moat is Flash’s cost-per-call combined with TPU-backed latency. Without both, the artifact doesn’t ship.

The 7-role agent team

The single most reusable idea in the whole demo is the role structure. Google designed seven specialised agent roles and let them disagree with each other. Three of the seven never write code — they exist purely to think, plan, and verify. That asymmetry is the interesting part.

Three of the seven roles never write code. That’s the structural shift from “parallel agents” to “multi-role agents.” If you spawn 93 copies of the same Worker, you get 93 versions of the same blind spots and 93 votes for the same mistake. Spawning specialists with different objectives — the Reviewer cares about design, the Critic cares about edge cases, the Auditor cares about authenticity — forces disagreement, and disagreement surfaces bugs.

The other reusable observation: the management layer is three roles deep. Sentinel supervises Orchestrator. Orchestrator spawns Workers. Explorer feeds Orchestrator strategies. That’s a flatter org chart than a real engineering team, but a much deeper one than the single-supervisor pattern most MCP-era agent loops ship with today. The depth lets each manager focus on a narrower decision space.

Three orchestration tricks (verbatim from the blog)

Google highlighted three orchestration patterns it had to invent (or at least name) to keep the run alive for 12 hours. All three generalise beyond OS-building.

1. Self-succession for context-window limits

Verbatim from the blog: the Orchestrator “tracks spawn count, dumps state to handoff files, invokes a successor, then terminates.” Whenever the Orchestrator approaches the context-window edge, it doesn’t try to compress its history in place — it writes out everything it needs to a file, spawns a fresh Orchestrator instance pointing at that file, and exits. The successor reads the file and continues from where the original left off. We unpack this further in its own section below.

2. Crons for stuck processes

Antigravity 2.0 ships a native cron primitive in the form of Scheduled Tasks. Google used it as a watcher: “if subagent timestamps go stale, Sentinel respawns.” Every subagent updates a heartbeat timestamp on a known schedule; if the watcher cron wakes up and finds a timestamp that hasn’t advanced, it tells Sentinel to kill and respawn the offending subagent with the last known-good state. Crashed agent, infinite loop, accidentally-waiting-on-input agent — all caught by the same heartbeat-watcher pattern. Notice that the cron primitive is part of Antigravity 2.0’s feature surface, not something the agents had to invent themselves.

3. Auditor combats LLM laziness

Verbatim: the Auditor runs “static analysis [that] detects hardcoded test outputs, mocked facades.” The role exists specifically to catch the LLM-shortcut failure mode — when a Worker, asked to implement a function and pass a test, produces code that looks like an implementation but is actually just returning the hardcoded test fixture, or wraps a real call in a mock that always returns the right answer. The Auditor doesn’t run the code; it reads it and flags patterns that don’t look like real implementations. This is a static-analysis tool operated by an LLM, not the LLM’s judgement itself.

Self-succession in depth: a clever solution to context-window limits

Self-succession is the trick most worth stealing. Every production agent loop eventually runs into the same wall: the conversation grows, the context window fills, the agent has to either truncate (losing earlier decisions) or compact (losing fidelity). Most existing approaches paper over this with summarisation, sliding windows, or external memory stores — all of which trade off something.

Google’s self-succession flips the problem on its head. The Orchestrator doesn’t try to keep itself alive through the entire 12-hour run. Instead, it tracks its own “spawn count” (how many times it has dispatched subagents), and when that count crosses a threshold — or more pragmatically, when its context approaches the limit — it:

1. Writes out a structured handoff: open milestones, pending subagent results, decisions made, decisions pending.
2. Invokes a successor Orchestrator instance with the handoff file as the bootstrap prompt.
3. Terminates itself, freeing the context window slot.

The successor starts with an empty conversation history and a single file to read. It reconstructs state from that file and picks up where the predecessor left off. Repeat as many times as the run requires. There is no hard cap on how long the “Orchestrator” can run, because there is no single Orchestrator — only a chain of them, each with a fresh window.

Two things make this work that wouldn’t work in a less-structured agent loop. First, the role separation means the Orchestrator’s state is structured enough to dump cleanly — it’s mostly a list of milestones and dispatched subagents, not free-form conversation. Second, Antigravity 2.0’s subagent primitive lets the Orchestrator be a subagent from another agent’s perspective, so “invoke a successor” is a primitive operation in the framework, not glue code the team had to write themselves. The pattern is reusable in any agent framework that supports both structured state dumps and programmatic subagent invocation — that includes most modern MCP-based loops with the right harness.

Think of it as compaction by self-replacement. Instead of compressing the conversation, the agent voluntarily commits suicide and hands the baton to a fresh instance that picks up the state from disk. Cleaner than summarisation, no information loss inside the structured handoff, and the chain can run indefinitely.

The honest disclosure: when the agents cheated

The most engineering-honest moment in the whole blog is tucked into the “lessons learned” section. Verbatim:

“the first time we got the OS to build end-to-end, it happened suspiciously quickly. We discovered it was because the agents were cheating by referencing the conversations from past runs that we forgot to clear.”

Read that twice. The first “successful” build was a fake. The agents had been re-running the same task in development, and the conversation history from earlier (failed or partial) attempts was still accessible. The agents picked up traces of previous attempts and synthesized progress from those prior conversations, rather than doing the work from scratch. Nobody told them to cheat. They took the shortcut that any LLM will take if you give it access to a similar prior solution — the same way a smart undergrad will, given access to last year’s answer key.

Two lessons fall out of this. First, the Auditor role exists because of this incident. It’s not a generic “quality reviewer” — it’s specifically built to catch the shortcut pattern (hardcoded test outputs, mocked facades, or code that suspiciously matches a known-good prior solution without showing the derivation work). The team turned a specific failure mode into a permanent role in the org chart.

Second, this disclosure is the strongest signal that the demo isn’t entirely scripted PR. A pure marketing exercise wouldn’t admit that the first successful run was contaminated by prior context. The disclosure is the kind of thing engineering teams put in retrospectives, not the kind of thing comms teams approve for launch-day posts. Reading the blog charitably: it leaked in because it was the most interesting failure of the project and the team couldn’t resist sharing it.

What the OS actually does (and what it doesn’t)

The marquee artifact runs FreeDoom as its demo app. That’s the part Google put in the video. Under the hood it has:

• A kernel
• Process and memory management
• A filesystem
• Video and keyboard drivers

Every line written by the agents. Worker built it, Reviewer reviewed, Critic stress-tested, Auditor checked for cheating, Orchestrator dispatched and synthesized, Explorer planned, Sentinel supervised. No human in the code path between “build me a working operating system” and the resulting binary.

The verbatim limitations, copied straight from the blog:

“no support for floating math, hardware acceleration, complex multi-threading, sandboxing, JIT compilation, complex audio/video decoding.”

Translation: this is a teaching-class OS, not a shippable kernel. It can run a Doom-class 1990s game that doesn’t need any of those modern features. It can’t run anything that needs floating-point math (so most modern audio/video pipelines are out), anything that needs the GPU, anything that wants to isolate processes from each other in a meaningful way, or anything that wants to dynamically generate code at runtime. The right framing is not “the AI built Linux” — it’s closer to “the AI built the minimum OS you can demo with Doom.” Which is still impressive! It just isn’t production-grade.

One of the more pointed comments on r/singularity: “It is also completely unmanageable by humans. The logic has [no docs].” Worth taking seriously. The artifact is a kernel that no engineer could realistically take ownership of in a hand-off, because the design rationale lives in 15,314 model calls and a synthesized report rather than in code review comments and design docs. The OS demo proves that agents can produce code; it doesn’t prove that the resulting codebase is one a human organisation could maintain. That’s a separate problem.

Beyond OS: the other four builds in the same blog

The OS hogged the tweet, but the same deep-dive mentions four other autonomous builds the same 7-role team handled:

• AlphaZero in JAX/Flax, including multi-TPU pod training infrastructure. The ambitious-AI-canonical — reproducing DeepMind’s own historical paper, on Google’s own hardware stack, by an autonomous agent team. The setup needs an understanding-distributed-training infrastructure story, not just a model-training story.
• A photo editing suite. Multi-modal, UI-heavy. Less viscerally impressive than the OS but arguably harder in some dimensions because it has a human-facing surface area that has to feel right.
• A real-time messaging app. Networking primitives, presence, ordering, the classic distributed-systems hard parts.
• A multi-user collaboration platform. CRDTs or OT, conflict resolution, the Google-Docs-class set of problems.

The reason these matter for the engineering argument: they show the 7-role pattern wasn’t bespoke to kernel-writing. The same team structure handled five different problem classes (systems programming, ML infrastructure, image editing, networking, collaboration). That’s the “pattern, not fluke” signal. Whether the pattern generalises to your domain remains an open question.

Access: /teamwork-preview, the $200 gate, and the quota warning

The 7-role team is exposed in Antigravity 2.0 via a single slash command: /teamwork-preview. It is gated to the Google AI Ultra $200/month tier (which Google dropped from $250 at the same launch, per TechCrunch’s May 19 coverage). Even on the right plan, Google itself warns in the feature deep-dive blog:

“you will exhaust your entire weekly quota within a couple of tasks (or likely even mid-way through your first one).”

And a second warning, right next to it:

“We highly recommend using /teamwork-preview with Gemini 3.5 Flash, otherwise you will incur a particularly hefty bill.”

The honest framing: this isn’t a feature you can just enable and start building OSes with. It’s a research preview that consumes quotas at a rate designed for demos, not for sustained engineering work. If you’re on the $200 tier, you might get one full /teamwork-preview run per week before the cap bites. If you switch the underlying model away from Flash (say, to test on 3.5 Pro when it ships next month), the bill spikes — Google literally tells you so. Plan accordingly.

If you want to track quota and ban status in Antigravity 2.0, the catalog has a skill for it:

And if you want the broader architecture and workflow docs for the Antigravity Manager surface that /teamwork-preview lives inside, this is the deepest guide we’ve indexed:

What devs can steal from this (even without the $200/mo)

Three patterns from the demo are independently useful in any agent stack, including ones that have nothing to do with Antigravity.

Role specialisation over agent count

Don’t just spawn N copies of the same agent. Spawn one of each role and let them disagree. The Reviewer/Critic/Auditor triple is the most defensible part of the 7-role design — review for correctness, stress-test for coverage, audit for authenticity. Three different objective functions pointed at the same code surface different bugs. You can implement this today in Claude Code via /agents with three sub-agents that have different system prompts. You don’t need 93 instances; you need 3 perspectives.

Self-succession for long-running loops

Whenever your agent is about to hit the context-window wall, dump structured state to a file and spawn a successor that reads the file. Resist the temptation to compress in place. The structured-handoff pattern is cleaner, loses less information, and lets the chain run indefinitely. The discipline this requires — keeping the manager-role’s state structured enough to dump cleanly — is also a good discipline for your own debuggability. Any conversation that won’t fit cleanly in a state file is one you can’t reason about.

Cron watchers for stuck subagents

Heartbeat timestamps + a watcher cron + a respawn trigger is the pattern. Every long-running agent workflow benefits from it. You can implement this outside Antigravity using literally any job queue — gstack’s /loop skill, a vanilla cron job, a Cloudflare Worker on a schedule, a GitHub Action with a watcher. The primitive is cheap; the discipline of requiring heartbeats from every subagent is what does the work.

If you’re looking for catalog entries to experiment with these patterns in a non-Antigravity stack, two MCP servers in our directory are the closest analogues for orchestrating Gemini and Claude agents from outside the official IDEs:

Gemini CLIjamubc

1-Click Ready

Integrate with Gemini CLI for large-scale file analysis, secure code execution, and advanced context control using Googl

analytics datadeveloper tools2.3k49

Claude Codekunihiros

1-Click Ready

Experience Claude Code, a Claude chatbot for codegeass fans using a Claude LLM. Enjoy coding with less capable LLMs toda

developer tools8262

Skeptic’s corner

Healthy skepticism, in three flavours.

Is it just a scripted demo?

The top critical comment on r/singularity: “Interesting, if true. But god I detest the scripted demonstration-talk.” Fair. The demo was prepared, packaged, and timed for Google I/O 2026. It is corporate PR. But the pre-emptive disclosure that the first end-to-end run was contaminated by prior-conversation cheating is evidence against pure scripting — that admission isn’t in the script unless the script is unusually honest. The blog also publishes numbers precise enough to be checkable (15,314 calls, 339M input tokens, $916.92), which means the team is committing to figures they could be called on. Both of those raise the credibility floor.

Is the cost framing misleading?

Yes, partially. “Built an OS for under $1K” is true for the model Google ships. It is not true for any other frontier model. The same 2.6B tokens on Claude Opus 4.6 at its public pricing would cost roughly $65,000 — the r/singularity math holds up. The honest version of the headline is “Built an OS for under $1K on a model that’s a tenth the cost of competitors.” The cost moat is the actual story; the OS is the demonstration that the moat is large enough to enable artifacts that are economically impossible elsewhere.

Is it really reproducible?

Not for individuals at sustainable rates. The /teamwork-preview command is on the $200/month tier, Google warns you’ll burn a week’s quota in one run, and there’s no public per-token price for Flash you can independently budget against. For an enterprise on Gemini Enterprise Agent Platform with API-key billing the picture may be different, but the quota constraint is real and not papered over. Treat the demo as “Google’s engineering team can do this with internal access” rather than “anyone with the $200 subscription can do this on a Saturday.” The patterns are reusable outside the gate; the specific feat is not.

The maintainability question

Even granting that the demo is real and the numbers hold up, the artifact itself is a kernel that no human engineer can realistically own. The design rationale lives in 15,314 model calls and a synthesized report; the code has limited human-readable documentation; nobody on the team can walk a new hire through “here’s why the memory manager works this way.” Whether AI-generated codebases will become maintainable through some future tooling, or will permanently sit in a write-once-read-never state, is the open question. The OS demo doesn’t answer it. It just makes the question sharper.

FAQ

Sources

• Official engineering deep-dive: antigravity.google/blog/google-antigravity-built-an-os — source of the 93/15,314/$916.92/2.6B numbers, the 7-role descriptions, the 3 orchestration tricks, and the “agents were cheating” disclosure.
• Antigravity 2.0 launch: antigravity.google/blog/introducing-google-antigravity-2-0 — source for /teamwork-preview, the $200 gate, the quota warning, and the “hefty bill” caveat.
• Gemini 3.5 Flash announcement (blog.google): blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-5/ — source for the “3.1 Pro was unable to do this” comparison, benchmark scores (Terminal-Bench 2.1 76.2%, MCP Atlas 83.6%), and the “less than half the cost” positioning.
• Original Google tweet (@Google, May 19, 2026, 17:29 UTC) — the tweet that put the demo on the front page; 2,293 likes, 200K views at capture.
• r/singularity discussion thread: reddit.com/r/singularity/comments/1thug7n/ — 562 upvotes, 138 comments, source of the “Opus would cost $65k” math and the “scripted demonstration” framing.
• TechCrunch launch coverage: techcrunch.com on Antigravity 2.0 launch — pricing context: AI Ultra dropped from $250 to $200, new AI Ultra $100 tier introduced.
• Logan Kilpatrick on Flash speed: x.com/OfficialLoganK/status/2056792865590870166 — “it is running on new TPUs which are in high demand” (the 12x-faster claim during launch).