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

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.

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.

1. 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.
2. 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.
3. 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.