Google Antigravity: What It Is and How to Use It on Production

Google Antigravity: What It Is and How to Use It on Production

Google Antigravity is Google’s agentic development platform: agents plan multi-step work, write code, run the terminal, drive a browser and hand back reviewable results. It is free for individuals, runs on desktop and in the terminal, and handles code well. What it cannot see by default is your running production system. This guide covers what the platform does, what it costs, how its permission model works, and how to give it live operational context safely.

TL;DR

• The problem: Antigravity agents reason over code and local tools. Debugging an incident also needs live cloud, Kubernetes, deployment and observability data, and agents without it guess.
• The takeaway: Antigravity is free for individuals, with App, CLI, IDE and SDK surfaces, and it supports MCP servers. That makes MCP the clean way to add production context without leaving the tool.
• The safe pattern: Connect a read-only operational layer. Opsphere is read-only by default and gives controlled access to production context without allowing direct infrastructure changes.
• The next step: Start with the Antigravity integration page, connect one environment, and test it on a past incident.

Table of Contents

• What Google Antigravity is
• What it costs and who can use it
• What Antigravity can do for development work
• Security model: what agents can touch by default
• The gap: code context without production context
• How MCP connects Antigravity to live systems
• Opsphere as the operational layer for Antigravity
• Practical workflows
• A safe rollout in five steps
• Decision criteria for any production-context layer
• Try Opsphere with Antigravity
• FAQ
• Sources

What Google Antigravity is

Google describes Antigravity as an agentic development platform in which agents reason over a codebase, use the editor, terminal and browser, plan multi-step work, run asynchronously, and return reviewable artifacts and verification results. It launched on November 18, 2025 as an AI-powered IDE with browser control and an agent-first form factor for end-to-end software tasks.

The key idea is delegation. In a classic AI-assisted editor, you type and the model completes. In Antigravity, you describe a task, an agent breaks it into steps, executes them, and reports back with plans, diffs, screenshots or browser recordings. Google’s stated rationale is that task-level summaries and artifacts are a more reviewable trust layer than either raw tool calls or only final code.

The four surfaces

Antigravity is not one application. Google’s overview lists four ways in:

The product homepage says it is available on macOS, Windows, Linux and Googlebook. The SDK path, per the getting-started docs, uses a Python 3.10+ virtual environment and the google-antigravity package.

Is it still a thing?

Yes. The changelog records Antigravity App version 2.26.0 on October 22, 2026, and the download page lists App 2.26.0 and CLI 1.4.0 with install commands for each operating system. Versions move quickly, so check the changelog rather than relying on any article, including this one, for the current number.

What it costs and who can use it

For individuals, Google’s pricing page shows $0 per month, with access to agent models, unlimited Tab completions and Command requests, and basic weekly rate limits. Higher individual tiers add more rate limits and flexible AI credit pools. Check the pricing page for current tier prices, since they can change.

Two availability limits matter before you plan a rollout:

• Geography and age. The FAQ says personal Google Accounts work in approved geographies, the product is currently unavailable to users under 18, and the regional availability page lists supported countries and territories.
• Enterprise. Google states the IDE is not supported for enterprise customers. Enterprise configurations should use the App or CLI. Google’s enterprise documentation says Antigravity can connect to Gemini Enterprise or Agent Platform, where sessions use Google Cloud terms, enterprise security controls, data-residency guarantees, request and response logging, and VPC Service Controls.

The practical consequence for platform teams: individual engineers can try it for free today, but a team standard should be decided with security and procurement, and on the surface your enterprise configuration actually supports.

What Antigravity can do for development work

Google’s feature overview lists a wide set of capabilities. The ones that matter most for engineering teams:

• Git worktrees and parallel agents. Several agents can work on isolated copies of a repository without stepping on each other.
• Project-scoped settings and permissions. Each project can carry its own rules.
• Multi-folder projects for services that span repositories.
• Browser tools and recordings, so an agent can launch a local server, test the result and show evidence.
• Scheduled tasks that repeat at the exact minute you choose.
• JSON hooks, terminal and Git review tools for fitting agents into existing habits.

The IDE documentation adds Agent and Tab features, parallel local agents and artifacts such as plans, diffs, diagrams, images and browser recordings.

This is a strong set for building and changing software. Notice what is missing from the list: the state of your running systems.

Security model: what agents can touch by default

An agent that can run commands deserves a careful look at permissions. According to Google’s documentation, agents request explicit permission by default before running terminal commands outside the isolated Terminal sandbox, and they are bounded to project folders unless you broaden access.

The settings documentation says you can control:

• terminal execution policy
• access to files outside the project
• sandbox mode
• project permissions
• MCP servers and skills
• telemetry and model settings

Telemetry deserves a deliberate decision. Per the same page, when it is enabled, interaction logs may be used to evaluate, develop and improve Antigravity and its supporting models. Set it according to your data policy, not by default.

The lesson for production work is to apply least privilege at every layer. An agent with a broad shell and cloud credentials can change things. An agent that only reads is far easier to approve, review and audit.

The gap: code context without production context

Imagine a latency alert on a checkout service. You ask an Antigravity agent to find the cause. It can read the repository, inspect recent commits and propose a fix. But the cause may sit outside the code:

• a deployment that rolled out 40 minutes ago with a changed environment variable
• pods restarting because of memory limits in a specific namespace
• a downstream managed database showing elevated connections
• an alert storm in which one signal matters and twenty are echoes

Without access to those facts, the agent produces a plausible theory from code alone. Engineers then paste logs, screenshots and dashboard exports into the chat by hand, which is slow, lossy and easy to get wrong during an incident.

The fix is to let the agent query live context through a governed channel. In Antigravity, that channel is the Model Context Protocol.

How MCP connects Antigravity to live systems

Antigravity supports MCP servers on every surface. Per Google’s MCP documentation, the CLI supports both local stdio processes and remote server configurations. Servers are defined in mcp_config.json, either globally or per workspace. A remote server entry uses a serverUrl, optional headers and a timeout. The IDE has an MCP Store for browsing and installing supported servers, plus a path for custom ones.

That means you can add an operational data source once and every agent session can use it. Two design decisions then matter:

1. Scope. Put the server in workspace configuration for a single service team, or in global configuration for an engineer who is on call across systems.
2. Capability. Prefer servers whose tools only read. If a tool can delete a resource, every prompt-injection path in your codebase becomes a path to production.

Opsphere as the operational layer for Antigravity

Opsphere does not replace Antigravity. It is the operational intelligence layer that gives Antigravity live production context. Opsphere unifies cloud infrastructure, Kubernetes, observability, CI/CD, security and engineering tools, and exposes them through MCP with more than 300 read-only operational tools. It is read-only by default, so agents get controlled access to production context without being able to make direct infrastructure changes.

Setup for the CLI is documented on the Antigravity integration page. The wider design is explained on the MCP operational gateway page.

What changes for the agent:

Opsphere connects to the tools you already run and keeps each tool as the source of truth. It does not ask you to duplicate telemetry or replace your stack.

Practical workflows

1. Investigate a production incident

Start with the symptom, not a hypothesis. A prompt such as “Checkout p95 latency rose at 14:10. Find what changed and what correlates with it” lets the agent query Opsphere for recent deployments, Kubernetes events, resource saturation and related alerts, then compare them against the code in your workspace.

Good practice: ask the agent to list the evidence for each hypothesis and what would disprove it. Opsphere’s focus on structured, evidence-backed investigation and parallel hypothesis testing fits this style. You review conclusions that point to specific data rather than a confident paragraph.

2. Check recent changes

Most incidents follow a change. Ask: “What was deployed to this service in the last 24 hours, and what else changed in its dependencies?” The agent can then read the relevant diff in your repository and line it up with the deploy timeline from the operational layer. The result is a short list of suspect changes ranked by timing and blast radius.

3. Correlate application failures with infrastructure and observability

A stack trace says a request failed. It does not say whether the node was under memory pressure or a dependency was throttling. With access to cloud, cluster and observability data, the agent can connect the exception in code to the infrastructure state at the same moment. This is where alert correlation and noise reduction pay off: fewer false leads in the context window means better reasoning.

4. Debug a failing rollout before it becomes an incident

When a canary misbehaves, the agent can read the manifest in the repository, check pod and event state through the read-only tools, and explain the mismatch. You still decide the fix and apply it through your normal pipeline, with review.

5. Generate and refine runbooks

After an incident, ask the agent to draft a runbook from the investigation steps that actually worked. Opsphere supports automated runbook generation, and the agent can turn the findings into a pull request that your team reviews.

A safe rollout in five steps

1. Pick the surface. Use the CLI or App if you are an enterprise, since the IDE is not supported there.
2. Start with one environment. A staging cluster or one non-critical production account is enough to prove value.
3. Keep access read-only. Confirm the tools your agent sees cannot mutate infrastructure. Keep Antigravity’s approval prompts on for any terminal command.
4. Replay a past incident. Give the agent the same symptom your on-call engineer saw and compare its findings with the real postmortem.
5. Measure. Track time to first credible hypothesis, time to resolution and the share of agent claims that cite evidence. Expand only if those numbers improve.

These are your own metrics. Avoid adopting outside benchmarks as targets, since incident mix varies widely between teams.

Decision criteria for any production-context layer

Whether you choose Opsphere or evaluate other types of tools, hold the layer to these questions:

• Read-only by design? Not merely “we recommend a limited role.”
• Does it reuse your tools or require you to move telemetry into a new store?
• Does it cover the whole path: cloud, Kubernetes, CI/CD, observability and security?
• Can you bring your own model? See how Opsphere handles bring-your-own AI.
• Is it auditable? You should be able to see which tools were called and what they returned.
• Does it work across your agent tools? Teams often use more than one. Opsphere also has integrations for Cursor, GitHub Copilot CLI and OpenCode.

For teams building around agents more broadly, the AI-native engineering teams page describes the operating model.

Try Opsphere with Antigravity

Opsphere offers a Community plan at €0 per month, a Developer plan at €19 per month, a Team plan at €500 per month and an Enterprise plan at €450 per month, plus Custom Solutions with no published price. See the pricing page for what each includes. Individual engineers can start small, and teams can validate on one environment before widening access.

CONNECT OPSPHERE TO ANTIGRAVITY: follow the setup guide, then run your last real incident through it.

FAQ

What is Google Antigravity?

It is Google’s agentic development platform. Agents plan and execute multi-step software tasks using the editor, terminal and browser, then return artifacts such as plans, diffs and recordings for review. It is offered as an App, CLI, IDE and SDK.

Is Google Antigravity free?

For individuals, yes: Google’s pricing page lists $0 per month with access to agent models and basic weekly rate limits. Higher individual tiers add rate limits and AI credit pools. Enterprise use runs through Google Cloud’s Gemini Enterprise arrangements, so check with your Google Cloud contact.

Can Antigravity see my production environment?

Not by itself. It works with your project folders and the tools you permit. To add live infrastructure and observability data, connect an MCP server. Opsphere is read-only by default, so agents can inspect production context without being able to change infrastructure.

Does Opsphere replace Antigravity?

No. Antigravity remains where you write code, run agents and review artifacts. Opsphere supplies the operational context through MCP: cloud, Kubernetes, observability, deployments and engineering systems.

Is Antigravity safe to use on company code?

By default agents ask permission before terminal commands outside the sandbox and stay inside project folders. Review your settings for execution policy, file access and telemetry, and use the enterprise configuration if your organization requires it. Your security team should make the final call.

Sources

• Choose your Antigravity, Google Antigravity Docs
• Introducing Google Antigravity
• Google Antigravity
• Get started, Google Antigravity Docs
• Changelog, Google Antigravity Docs
• Google Antigravity download
• Google Antigravity pricing
• FAQ, Google Antigravity Docs
• Antigravity IDE overview
• Enterprise, Google Antigravity Docs
• Feature overview, Google Antigravity Docs
• Settings overview, Google Antigravity Docs
• MCP, Google Antigravity Docs

Recommended

• Antigravity CLI MCP Integration

This article is provided for general informational purposes only and does not constitute professional, legal, security, or compliance advice. Please evaluate recommendations against your organization’s specific environment and requirements.