Distribution-Path-Agnostic Antigravity CLI Automation: Betting on Both the Consumer and Google Cloud Editions

The 7/1 announcement began offering the Antigravity CLI via the Gemini Enterprise Agent Platform too. Here is a design that abstracts your personal automation to run on either the consumer or Cloud edition, laid out with a wrapper and capability-detection scripts.

Antigravity CLI¹² automation⁷² abstraction design scheduled runs² Google Cloud³

✦ Premium Article

When Gemini CLI ended consumer availability on 6/18, I hurriedly rewrote several nightly batches. Because the invocation commands were embedded inline, the migration's impact was scattered across the whole script.

With the 7/1 announcement, Antigravity 2.0 and the Antigravity CLI began being offered to Google Cloud customers via the Gemini Enterprise Agent Platform as well. For now the consumer edition on my machine is plenty for indie work, but the fact that distribution now runs through multiple paths cannot be ignored. To avoid the same rut, here is a design that abstracts automation into a form that "runs on the CLI of any path," laid out with the actual scripts.

Why a path-aware design is needed

Even the same Antigravity CLI can carry different surrounding assumptions depending on how you obtained it: how auth is threaded, the default model, how usage limits land, the names of environment variables. Even when the command body is identical, if this periphery differs, a script fails silently the moment it crosses paths.

What hurt about the Gemini CLI shutdown was not the feature disappearing so much as the fact that the invocation details were hardcoded all over the code. Migration should have been "swap one entry point," but in practice it started with grepping every file.

The lesson is simple. Wrap external-tool invocations in a single layer, on the assumption that the path can change. Do that and, when distribution shifts next, you only fix that one layer.

Confine invocation to a single wrapper

First, stop hitting the CLI directly from automation scripts and call it through a thin wrapper. Every per-path difference lives only inside this wrapper.

#!/usr/bin/env bash
# agy-invoke.sh — single entry point for Antigravity CLI invocation
# on any distribution path, upstream scripts call only this wrapper
set -euo pipefail
 
# choose the path via env var; default is the consumer edition
: "${AGY_CHANNEL:=consumer}"   # consumer | gcp
 
case "$AGY_CHANNEL" in
  consumer)
    AGY_BIN="${AGY_BIN:-agy}"
    # consumer auth depends on local login state
    ;;
  gcp)
    AGY_BIN="${AGY_BIN:-agy}"
    # via Gemini Enterprise Agent Platform; state project and authz
    export GOOGLE_CLOUD_PROJECT="${GOOGLE_CLOUD_PROJECT:?required on the gcp path}"
    ;;
  *)
    echo "unknown AGY_CHANNEL: $AGY_CHANNEL" >&2; exit 2 ;;
esac
 
# upstream passes only model and prompt; path details stay hidden
exec "$AGY_BIN" run \
  --model "${AGY_MODEL:-gemini-3.5-flash}" \
  "$@"

Upstream batches call this wrapper only as agy-invoke.sh --prompt "...". To switch paths, you change AGY_CHANNEL alone; individual tasks are untouched. This simple principle — one entry point — is what pays off.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦A compatibility-layer design that isolates what can differ between the consumer and Cloud editions

✦A preflight script that detects CLI capabilities before a run and absorbs path differences

✦Turning the pain of the Gemini CLI shutdown into preparation so the next migration doesn't repeat it

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

Detect CLI capabilities before running

Different paths do not guarantee the same flags or models are present. Before running a production batch, I insert a preflight that detects whether the needed capabilities exist. Rather than running on a false assumption and dying midway, stopping explicitly at the entrance is far easier to handle in unattended operation.

#!/usr/bin/env bash
# agy-preflight.sh — verify CLI capabilities and path before a batch
set -euo pipefail
 
fail() { echo "PREFLIGHT FAIL: $1" >&2; exit 1; }
 
# 1. is the binary callable
command -v "${AGY_BIN:-agy}" >/dev/null || fail "CLI not found"
 
# 2. is the required model available (check --list-models output)
want_model="${AGY_MODEL:-gemini-3.5-flash}"
"${AGY_BIN:-agy}" --list-models 2>/dev/null | grep -q "$want_model" \
  || fail "model $want_model unavailable on the current path"
 
# 3. does it support non-interactive JSON output (required for automation)
"${AGY_BIN:-agy}" run --help 2>/dev/null | grep -q -- "--json-events" \
  || fail "no --json-events; the automation premise breaks on this path"
 
# 4. on the gcp path, verify project authorization
if [ "${AGY_CHANNEL:-consumer}" = "gcp" ]; then
  [ -n "${GOOGLE_CLOUD_PROJECT:-}" ] || fail "GOOGLE_CLOUD_PROJECT unset"
fi
 
echo "preflight ok (channel=${AGY_CHANNEL:-consumer} model=$want_model)"

Placing this preflight at the head of each batch stops most path-difference accidents with "one line before start." I put it in all the nightly updates for my four blogs, and when I experimentally switched paths, the breakages showed up instantly in one list.

Keep a table of what can vary per path

Making path-dependence explicit as a table, not in your head, reduces missed checks during migration. Here is an excerpt of the mapping I actually maintain — a template you fill in for your own setup.

Aspect	Consumer edition	Cloud edition (via Enterprise Agent Platform)	Absorbed in
Auth	local login state	project + authorization	wrapper case clause
Default model	account plan dependent	project setting dependent	set AGY_MODEL explicitly
Usage limits	personal plan ceiling	org allocation	backoff and batch spacing
Env vars	minimal	GOOGLE_CLOUD_PROJECT and others	verified in preflight

The key is the "absorbed in" column. Always push path-dependent differences into either the wrapper or the preflight. Not leaking path knowledge into upstream task logic is the crux of keeping the abstraction intact.

The routine for the day you switch paths

On a day I actually test or move a path, I take just these three steps. Fixing the procedure lets me verify without stopping the production nightly batches.

First, run only the preflight with AGY_CHANNEL=gcp as a one-off and confirm capability detection passes. If it fails here, the batch body never runs at all.
Next, run a single low-impact task on the new path and eyeball whether the output has the same shape as before. I use a light job that merely reads an AdMob setting for a wallpaper app as this test bed.
If there are no issues, flip AGY_CHANNEL and check the success of all tasks in the next morning's logs.

The caution here is not to tip every batch onto the new path at once. With apps on both the App Store and Google Play, a simultaneous break of the nightly updates has a large blast radius, so I recommend a one-at-a-time warm-up without exception.

No need to switch paths now, but the preparation is light

Honestly, for me as an indie developer today, the motivation to move to the Cloud edition is not yet strong. The consumer edition runs the nightly auto-updates just fine. I still put this abstraction in early because the cost of preparation is extremely light.

Adding the wrapper and preflight is half a day's work, and existing batches migrate by swapping one invocation line at a time. Against that, scrambling to fix things after a path actually shifts is far more expensive, as I learned firsthand in the earlier Gemini CLI shutdown.

If you run tool-dependent automation for the long haul, the habit itself — "close the entrance into a single layer" — becomes an asset. It is unglamorous, but it is a design that has helped me every time distribution shifted. If you carry a dependency on an external CLI the same way, I hope this helps you prepare.

Thank You for Reading

Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.