Google published version 4.0.0 of its Google Ads API Developer Assistant on Tuesday, August 25, 2026, rebuilding the tool as a globally installed plugin for the Antigravity and Claude Code agent environments and breaking compatibility with every earlier installation.

The announcement appeared on the Google Ads Developer Blog under the name of Bob Hancock of the Google Ads API Team, the same author who signed the version 2.0 release six months earlier. Its framing is blunt about what the change costs. According to Google, this is a major release that is not compatible with prior releases, because earlier versions relied on a local workspace project structure while version 4.0.0 is built on a standardised plugin architecture installed to be globally available.

That single sentence carries the operational weight of the release. Developers running the assistant from a cloned project directory cannot upgrade in place. They read the prerequisites file, run a platform-specific installer, and start again.

What the assistant does

The Google Ads API Developer Assistant is a free, Apache-licensed tool that sits inside an AI coding environment and supplies it with Google Ads API domain knowledge. Rather than answering from a general model's training data, it grounds responses in official API definitions and client library source code held locally on the machine.

According to Google, the tool generates integration code across Python, Java, PHP, .NET and Ruby; validates Google Ads Query Language syntax, field compatibility, date segmentation and zero-impression rules before a query runs; inspects Protobuf schemas on demand to confirm that resource fields, data types and enum definitions exist in the active API version; diagnoses offline conversion upload failures; navigates manager account hierarchies; and constructs Performance Max listing filters.

It also runs ad hoc reports. A request phrased in plain English is converted into a GAQL query, validated, executed against the account, and streamed back into the chat session as a formatted table. Results can be written to CSV in a directory the developer names.

The repository documentation gives a sharper picture of the boundaries than the blog post does. The assistant generates code for mutate operations - creating campaigns, adding users - but will not execute them. According to the repository README, that execution policy exists so developers retain full control over changes to their accounts, and generated mutate code must be reviewed and run manually outside the tool.

The contrast with how other platforms have approached the same problem is instructive. Google shipped an open-source Model Context Protocol server for the Ads API in October 2025 in read-only mode, and the Developer Assistant holds the same line at the write boundary while going considerably further on the read and diagnose side.

The architecture change

Version 4.0.0 replaces a workspace project with a plugin bundle. Rules, skills and diagnostic commands are modularised into a self-contained package that can be installed, updated and managed across multiple environments and projects rather than per repository.

The repository lays out the structure. A plugins directory holds commands, skills, behavioural rules, background sidecar microservices, cloned client libraries and a Model Context Protocol configuration file. A separate config directory holds two small state files: the cached API version and an optional default customer ID.

Two master configuration files, AGENTS.md and CLAUDE.md, act as what the repository calls the system contract. They govern five behaviours: automatic discovery and locking of the latest active API version, cached in config/api_version.txt; parity verification between the installed google-ads Python package and the locally cloned client library definitions; strict ruff linting applied to all generated Python before it is saved or displayed; programmatic GAQL validation against field metadata and compatibility boundaries; and a prohibition on running unreviewed mutate operations.

The version cache matters more than it sounds. On the first run of a session the assistant identifies the latest stable API version and asks for confirmation. Once confirmed, the version is written to a file and reused for every subsequent request in that session. Forcing a change means deleting or editing that file. Given that the Google Ads API moved to monthly releases in January 2026, raising major versions from three to four a year, a cached and confirmed version number is a defence against generating code against a version the account is not on.

Two hosts, one plugin

The release introduces dual-platform support. Antigravity gets native support with global and workspace plugin registration. Claude Code gets full integration with its CLI plugin system, including custom slash commands.

This is the part of the release with the widest implication. The assistant was previously described by Google's own developer relations team as a Gemini CLI extension, a characterisation that appeared in the Ads DevCast episodespublished between March and May 2026. Version 4.0.0 targets Antigravity and Claude Code by name. Google is now shipping first-party advertising tooling into a coding agent built by a competitor.

Antigravity is Google's own agent development platform, introduced alongside Gemini 3 in November 2025 and rebuilt at Google I/O 2026 on May 19 as Antigravity 2.0 with a separate CLI. The Antigravity harness is not a peripheral product inside Google; Koray Kavukcuoglu, chief technology officer of Google DeepMind, has described the externally available SDK as the same one Google's own Search team uses, a point PPC Land documented in coverage of the agentic infrastructure shift.

Installation scripts cover Linux, macOS via bash, and Windows via PowerShell. The Antigravity path writes the plugin to a directory under the user's home folder; the Claude Code path registers the repository as a local marketplace and installs through the Claude command line interface. Both installers accept flags to pull additional client libraries for PHP, Ruby and .NET alongside the default Python clone.

Prerequisites are specific. Claude Code requires Node.js version 18 or higher. Python 3.10 or newer must be present on the system path because Python is the default language for all code generation and execution. Credentials files live in the home directory under per-language naming conventions: google-ads.yaml for Python, google_ads_php.ini for PHP, google_ads_config.rb for Ruby.

Ten slash commands

The commands are the concrete surface of the release, and each has a natural language equivalent for developers working in Antigravity.

Validation and inspection. The /validate-gaql command dry-runs a query through the API validate_only parameter. The /inspect-object command reads API resources, nested messages and enum definitions directly from the local Protobuf definitions.

Account and diagnostics. The /get-cids command maps client hierarchies and returns sub-account customer IDs under manager accounts. The /troubleshoot-conversions command investigates conversion upload summaries and pre-validates files, writing structured diagnostic reports to a saved data directory. The /pmax-filter command generates product partition trees and webpage URL exclusions for Performance Max campaigns.

Explanation. Three commands - /explain, /step-by-step and /assistant-tutorial - produce standardised multipart explanations, step breakdowns and interactive tutorials.

Environment. The /sync-client-libs command synchronises local client libraries, optionally scoped to a single language. The /ext-version command reports the active Google Ads API version.

Determinism over round-trips

The performance section of the announcement is where the engineering argument sits, and it is an argument about not using a language model where a script will do.

According to Google, the release cuts token consumption through progressive disclosure, loading only the rules and schemas a given task requires rather than the full ruleset on every turn. On-demand skill execution and targeted command routing shorten end-to-end task completion. Skills and commands run ephemerally as short-lived child processes only when called, which Google says drops system resource usage to zero when idle and eliminates daemon overhead entirely. Streamlined execution pipelines remove background process overhead during sessions.

Two further items address the file system rather than the model. Cutting unneeded files from the plugin tree stops file watchers, linters and integrated development environment indexers from scanning what Google describes as tens of thousands of unused Protobuf and SDK files. Caching API version and Protobuf schema resolution avoids repetitive remote metadata or reflection calls when the assistant inspects standard fields, resources and enums.

The last item is the most specific and the most quantified. According to Google, instead of the language model guessing or iteratively debugging GAQL syntax across three to four round-trips, a local validator checks fields, resources, zero-impression metrics and date clauses in a single step.

That is a claim about cost as much as speed. Every failed round-trip is a full model call. Collapsing three or four of them into one deterministic local check changes the economics of running the tool at agency scale, where a single practitioner may generate dozens of queries in a working session. It also changes the failure mode: a validator that reports a missing field returns the same answer every time, which a model iterating on an error message does not.

Version parity and the mismatch warning

The assistant treats the locally cloned google-ads-python source as the authority for Protobuf schemas, resource definitions and enum descriptors, while executing generated code through the google-ads package installed in the environment. Those two can drift apart, and the release adds explicit machinery to catch it.

Tool scripts compare the installed package version against the version metadata in the local client library clone. On a mismatch, the assistant emits a warning banner naming both versions. Three remedies are documented: synchronise the client libraries, upgrade the runtime package through pip, or run a full update script.

At session startup the assistant executes what the repository calls a validate before act and interactive sync directive. It checks both its own repository and the local client libraries against upstream GitHub releases in check-only mode, then prompts before downloading anything. The example prompt in the documentation shows both an assistant version and a client library version step, with a Python client library moving from 25.1.0 to 26.0.0.

The documentation is candid about a residual limitation. The underlying model may have been trained on an older API version and may generate code using deprecated fields. Execution errors often provide enough feedback for the assistant to self-correct on the next attempt using the local client library context, which is why the session begins by pinning a version.

Discrepancies in the source material

Three inconsistencies appear between the blog announcement and the repository documentation.

The GitHub releases panel labels the current release v4.0.0.0 (Plugin), a four-part version string, while the blog post and the README both use v4.0.0. The repository TL;DR describes the assistant as powered by the Antigravity (v4.0.0) and Claude Code agent frameworks, attaching the assistant's own version number to the host platform rather than to the assistant.

The README also retains a Gemini reference in a section describing the context_dir flag, stating that supplying a codebase path allows Gemini to include application logic in its reasoning. The same document elsewhere describes dual-platform support for Antigravity and Claude Code. The Antigravity installation path likewise writes to a directory named for Gemini, a residue of the tool's earlier form.

Finally, the blog lists code generation across Python, Java, PHP, .NET and Ruby without qualification. The README adds the constraint that only Python, PHP and Ruby output can be executed directly; Java and C# code must be compiled and run separately, which the documentation attributes to security policies.

Repository signals

The public repository carries 96 stars, 14 forks and 185 commits across two branches and thirteen tags, with thirteen releases listed. Two contributor accounts appear, both belonging to Bob Hancock. Language composition is Python at 67.1 percent, PowerShell at 16.9 percent and shell scripting at 16 percent - a distribution that reflects how much of the work is installation and lifecycle management rather than the assistant logic itself.

The most recent commits, all dated to the week before the announcement, describe updated governance directives, an audited and reorganised FAQ, a continuous integration workflow change, removal of personally identifiable information left over from testing, and update scripts made more resilient to temporary failures. A commit three weeks prior added guardrails for saving code and data.

Why this matters to advertising teams

The assistant is not an advertiser-facing product, and no campaign setting changes because of this release. Its relevance runs through the people who build and maintain the pipelines that agencies and advertisers depend on.

Google itself has quantified the tool's pull on that population. When the company acknowledged a developer token application backlog on February 6, 2026, it named three causes for the surge in applications: the new Explorer Access tier, the Google Ads API MCP server, and the Developer Assistant. The backlog was severe enough that Google later cut review times to hours through a brand verification pilot announced on July 7, 2026. A tool that generates that much inbound demand for API credentials is shaping who gets to build advertising software.

Timing sharpens the point. Version 4.0.0 arrived six days after Google shipped Ads API v25.1 on August 19, 2026, and roughly a month after v25 removed the CustomerLifecycleGoal and CampaignLifecycleGoal resources outright on July 22, 2026, breaking any pipeline that configured lifecycle goals programmatically. Under a monthly cadence, a developer maintaining production integrations now absorbs a version change roughly every four weeks. Tooling that pins an API version, validates queries against that version's actual field metadata, and warns when the runtime package and the schema source diverge addresses a problem the release schedule created.

The bind is that this particular release adds one more forced migration to the pile. The tool built to reduce version churn cost has itself become a version churn cost, with no upgrade path from the workspace layout to the plugin layout.

There is a competitive dimension too. Google spent 2026 consolidating developer surfaces, merging its advertising and measurement documentation into a single hub on April 6 and adding Discord channels for the Display and Video 360 APIin March. Shipping the Ads API assistant into Claude Code extends that consolidation past Google's own tooling boundary. Advertising engineering teams do not standardise on one vendor's coding agent, and a plugin that installs into two hosts reaches more of them than an extension tied to one.

For agencies weighing whether to adopt it, the practical read is narrow and clear. Natural language prompts still produce code that a human reviews before anything mutates an account. The assistant reads, validates, explains and diagnoses. It does not spend money.

Timeline

Summary

Who: Google's Ads API Team, with the announcement authored by Bob Hancock. The release affects developers, marketing technology vendors, agency engineering teams and in-house advertising operations staff who build integrations against the Google Ads API.

What: Version 4.0.0 of the Google Ads API Developer Assistant, a rebuild of the tool from a local workspace project into a globally installed plugin bundle, with native support for the Antigravity and Claude Code agent environments, ten slash commands, code generation across five languages, deterministic local GAQL validation, cached API version and Protobuf schema resolution, and version parity checks between the installed google-ads package and locally cloned client libraries. The release is explicitly incompatible with earlier versions.

When: Published Tuesday, August 25, 2026, on the Google Ads Developer Blog. Repository commits supporting the release are dated to the preceding week. Version 2.0 shipped February 26, 2026.

Where: The Google Ads Developer Blog and the googleads/google-ads-api-developer-assistant repository on GitHub, distributed under the Apache License 2.0. Installation scripts cover Linux, macOS and Windows.

Why: A monthly Google Ads API release cadence adopted in January 2026 has increased the rate at which fields, resources and enums change, raising the cost of code generated against stale schema knowledge. The plugin architecture allows one installation to serve multiple projects and environments, local validation replaces model round-trips that cost tokens and time, and dual-host support extends Google's first-party advertising tooling into a coding agent it does not own.