Moving My Automation Off the Gemini CLI Before the June 18 Shutdown

Make It a "Won't Break" Migration With Structured Output

What troubled me most in the CLI days was that output was unstable: sometimes prose, sometimes JSON. Downstream scripts parse that output, so every time the shape shifted, they failed. If you are moving to the SDK, fix the output shape here with response_schema.

from pydantic import BaseModel
 
class ReviewLabel(BaseModel):
    sentiment: str
    category: str
    needs_reply: bool
 
def classify_structured(review_text: str) -> ReviewLabel:
    response = client.models.generate_content(
        model="gemini-2.5-flash",
        contents=review_text,
        config={
            "response_mime_type": "application/json",
            "response_schema": ReviewLabel,
        },
    )
    # parsed holds a ReviewLabel instance
    return response.parsed

Pass a schema and you receive a typed object back. Downstream code no longer parses text and can work with attributes like label.needs_reply. If you run into the schema being ignored, what to do when structured output schema validation fails is a useful reference.

Prepare for Retries and Rate Limits

In the CLI days I got away with a sloppy stance: if it fails, the next day's job picks it up. But wiring an unattended job directly to the API makes it easy for a transient 429 (rate exceeded) or 503 (overload) to take down the entire nightly batch. Design it so the failures you can swallow get swallowed, using exponential backoff.

import time
from google.genai import errors
 
def classify_with_retry(review_text: str, max_attempts: int = 5) -> ReviewLabel:
    delay = 1.0
    for attempt in range(1, max_attempts + 1):
        try:
            return classify_structured(review_text)
        except errors.APIError as e:
            # 429 / 503 are transient, so wait and retry
            if e.code in (429, 503) and attempt < max_attempts:
                time.sleep(delay)
                delay = min(delay * 2, 30.0)
                continue
            raise
    raise RuntimeError("max_attempts exhausted")

The thing to watch here is to always cap the wait. Uncapped exponential backoff means a sustained overload can leave a job sleeping for hours. I cap mine at 30 seconds, and if that still fails, I give up and defer to the next day. For the thinking behind rate limits themselves, see resolving Gemini API rate limit errors.

Measure Cost and Latency Before and After

What you cannot skip in the migration decision is a feel for what it actually costs. In the CLI days it was hard to see which model ran internally and how many tokens were consumed, so cost was a guess. With the SDK you can read per-call token counts from usage_metadata.

def classify_and_measure(review_text: str):
    response = client.models.generate_content(
        model="gemini-2.5-flash",
        contents=review_text,
        config={
            "response_mime_type": "application/json",
            "response_schema": ReviewLabel,
        },
    )
    usage = response.usage_metadata
    return {
        "label": response.parsed,
        "input_tokens": usage.prompt_token_count,
        "output_tokens": usage.candidates_token_count,
    }

Here is a rough comparison from my own setup, classifying about 200 reviews in a nightly job before and after. The numbers move with prompt length and load, so treat them as a trend within my environment.

What helped most, in practice, was not the response time but the drop in parse failures. Back when I pried open CLI output with regular expressions, roughly one item in twenty came out malformed, and I fixed it by hand the next morning. After switching to structured output, that cleanup nearly vanished, and total processing time dropped by about 40%. For a production design around cost tracking with usage_metadata, I go deeper in tracking cost with usage_metadata in production.

The Call to Drop the CLI and Lean on the API

The official guidance is to migrate to the Antigravity CLI. For interactive use, I think that is the natural choice. But for unattended automation, I chose to drop the CLI dependency itself and lean on the API.

There are three reasons. First, the CLI is a layer designed for humans to converse with, and its output format and behavior can change across versions. For the foundation of an unattended job, an API with a stable contract feels safer. Second, the tooling production needs—structured output, retries, cost measurement—comes naturally with the API. Third, moving from one CLI to another leaves the "someday another shutdown notice arrives" risk in place. Not wanting to repeat a migration like this one is, honestly, the lesson of years of indie development.

Conversely, rewriting interactive, exploratory use over to the API feels excessive. Leave that to the Antigravity CLI, and harden only the unattended parts onto the API. For solo development run in limited time, that line feels realistic to me.

What to Do Before the Cutover

There is not much time left. The one thing worth doing today: run grep to surface your unattended jobs that depend on the CLI, and rewrite just the single one you would most hate to lose into the retry-plus-structured-output version from this article. Once one runs, the rest are repetitions of the same pattern.

I am still mid-migration myself, with small adjustments ongoing, but heading off a nightly job that quietly stops was a real relief. I hope it helps anyone carrying the same kind of CLI-dependent automation prepare in time.