Open AG Patcher: what a GPL-3.0 Antigravity region patcher does and does not change

The patch operates on local files and nothing else

This is the sentence the README is most careful about, and it is worth repeating before anything else. In the section on the HTTP 403 error it states that the patcher changes only local files of Antigravity or Antigravity CLI and cannot grant your account a licence or change what the Google API returns.

That single constraint explains most of what this project does and, more usefully, most of what it fails to do. A region check that lives in local application files is something a local file edit can address. A check that lives in a server response is not, and no amount of local patching changes the fact that Google decides what your account is entitled to. The README makes the same point about the HTTP 500 Internal Server Error case, where it says there is nothing to be done about it and recommends changing account, ideally to a region where Antigravity IDE officially works or where a paid subscription was bought, noting that the paid utility did not solve it either.

The surface it targets is broader than one application. The README describes it as covering Antigravity 2.0, Antigravity IDE, Antigravity CLI and the Google Antigravity extension for Visual Studio Code, which V1.3.4 of 2026-08-22 specifically refined. The intended effect is to clear regional restrictions without needing a VPN or changing the region of a Google account.

One note on scope and provenance. The repository description, in Russian, calls this a patcher for lifting regional restrictions, and the README positions the project as an open-source counterpart to a commercial utility. If you are evaluating it, that is the honest framing: it is a regional-restriction patcher for a Google product, not a configuration tool, and the sections below cover what that means in practice.

Five binaries per release, each with its own VirusTotal link

The release engineering is the part of this repository that holds up under scrutiny, and it is worth describing precisely because patchers of this kind rarely bother.

Every release publishes five platform artifacts. The naming is consistent and descriptive: `Open_AG_Patcher_Windows_x64.exe`, `Open_AG_Patcher_Windows_arm64.exe`, `Open_AG_Patcher_Linux_x64`, `Open_AG_Patcher_Linux_arm64`, and `Open_AG_Patcher_macOS`. Note what that implies about the project. It ships native arm64 Windows and Linux builds rather than relying on emulation, and it treats macOS as a first-class target, which the release notes confirm rather than imply.

Each of those five artifacts is accompanied by a VirusTotal file-analysis link in the release body. There is also a GitHub Actions run link and a full changelog comparison link, and the release body carries a SourceForge download mirror badge. Publishing a hash-verifiable scan link for every binary is the practice you would want from a tool that rewrites files in a vendor application, since the alternative is asking users to trust an opaque executable by name alone.

The repository topics reinforce the packaging story: alongside `python`, `python3` and `pip` there are `nuitka` and `pyinstaller`, both Python-to-native compilation toolchains, plus `build` and `exe`. The source language is Python, and the shipped artifacts are compiled executables, which is why the tree contains no test fixtures or example projects to read: the deliverable is the binary, and the code in `source/` is the input to a compile step rather than a library someone imports.

The licence is GPL-3.0, which for a tool that patches someone else's product is a choice with consequences. A GPL licence obliges redistribution to carry the same terms, so anyone shipping a modified build of this patcher must publish their source too. The practical effect is that the closed-source utility this project positions itself against and the open one cannot easily be reconciled into a single codebase.

Two documented failure modes, one of them unfixable by design

The README devotes more space to errors than to usage, which is unusual and useful. Two error classes get their own sections, each with a real captured payload rather than a paraphrase.

The first is HTTP 500 Internal Server Error from an Antigravity IDE request. The included capture shows a Trajectory ID, a TraceID, a Sherlog field left empty, and a response header set including a Server value of ESF, a Server-Timing value, and an X-Cloudaicompanion-Trace-Id. The body is a small JSON object with code 500, the message Internal error encountered, and a status of INTERNAL. The README's guidance for this case is blunt: change account, preferably to a region where the IDE officially works or where a paid subscription was purchased, because the paid utility did not resolve it either.

The second is the one that explains the first. If you see HTTP 403 Forbidden with a reason of `SUBSCRIPTION_REQUIRED`, or the message You do not have a valid license of this product, or Agent execution terminated due to error, the README says plainly that this is not a local patch problem and not the Eligibility Check screen. The payload makes the origin obvious:

+{
  "error": {
+    "code": 403,
+    "details": [
+      {
+        "@type": "type.googleapis.com/google.rpc.ErrorInfo",
+        "domain": "cloudaicompanion.googleapis.com",
+        "metadata": {
+          "error_number": "1001",
+          "uiMessage": "true"
+        },
+        "reason": "SUBSCRIPTION_REQUIRED"
+      }
+    ],
+

The `cloudaicompanion.googleapis.com` domain in that payload is the giveaway. The rejection is arriving from a Google service, so it is decided by your account's licence and access state, not by anything on your disk. The stated remedies are to change your Google account region or use an account registered where Antigravity officially works, and if that does not help, to buy an official subscription.

The 1.3.4 release notes confirm this boundary was reached from the other direction. That release refined the patch for the Antigravity extension for Visual Studio Code and explicitly stated that it does not fix the licence error tracked as issue #3501, because that problem is on Google's server side. A project documenting the edge of its own reach in release notes is doing something rarer than claiming a fix.

What the local patch is actually buying, priced against Google AI plans

The README lists Google's own subscription tiers, which gives the patch a frame of reference. The figures are in Russian roubles.

Google AI Plus is listed at 445 roubles per month with 400 GB of storage and Gemini limits increased by a factor of two. Google AI Pro is 1,790 roubles per month with 5 TB of storage and limits increased fourfold. Google AI Ultra starts at 6,990 roubles per month with storage from 20 TB and limits increased twentyfold. Each links to the Google AI plans page, and each carries a note that terms and conditions apply.

Those tiers are the reason the regional restriction matters to this project at all. Antigravity is Google's AI coding product, and access to it is tied to an account whose region and subscription status Google evaluates server-side. The local patch removes a client-side obstacle to reaching the product. It cannot create an entitlement, which is why the price list in the README sits directly under the explanation of the 403 rather than under the installation instructions.

Read together, the two error sections and the price list amount to an honest cost accounting. If your account is already in a supported region with an adequate plan, the patch has nothing to remove and you should leave your installation alone. If your account is not, the patch may get you to a screen and then stop, because the next thing the product asks Google's servers about is whether you are entitled to what you are asking for.

The same boundary has a second implication for anyone reading this as a developer. Modifying the local files of a commercial product is a different activity from configuring a supported extension, and the repository's own topics, which include `unlocker` and `unlocker-tool` alongside the technical ones, are candid about the category. The GPL-3.0 licence governs the patcher's own code. It says nothing about the licence of the Google product it modifies, and that is a question for the account holder rather than for the licence file.

V1.3.5 replaced files atomically and validated the patch

The most technically interesting change in the recent history is not about regions at all. V1.3.5, published on 2026-09-02, added atomic file replacement and patch validation for safe patching and restoration on POSIX systems, and it points at pull request 127 for the detail.

Both halves of that matter, and they matter for the same reason. A patcher that rewrites files inside an installed application has a failure mode that most tools do not have: an interrupted write leaves the target application in a state where neither the original nor the patched version is intact. Atomic replacement is the standard answer to that. Write to a temporary location, then move into place, so the swap either happens or does not.

Patch validation is the other half, and it addresses a different failure. If the patcher validates what it found before it changes it, then running it against a version of Antigravity it was not built for produces a clear refusal instead of a mangled installation. For a tool that patches files belonging to software you do not control, and that will inevitably be run after a vendor update, that is the difference between a tool that refuses politely and one that leaves your IDE broken.

The POSIX qualifier is notable too. Atomic rename semantics differ across platforms, and specifying POSIX means the behaviour is defined on Linux and macOS, which are two of the five shipped targets. V1.3.6, published the next day on 2026-09-05, then fixed a backup error on macOS, tracked as issue 130. A macOS-specific backup bug three days after a POSIX-specific safety change is a fair illustration of how much platform-specific work this packaging represents.

Taken together, V1.3.5 and V1.3.6 read as a maintainer hardening a tool whose failure modes are unusually costly, which is a reasonable thing to see in a project whose topic list includes windows-application.

Four social channels, a video guide, and a very short source tree

The repository is small in a way that is worth describing precisely, because the shape tells you where the work lives. The tree has five entries: `.github/`, `.gitignore`, `LICENSE`, `README.md` and `source/`. There are no example directories, no test fixtures and no documentation site in the tree.

That means the code is in `source/` and you have to open it. The README does not summarise the architecture, describe the patch targets file by file, or explain how it detects which Antigravity build it is looking at. For a reader who wants to understand the mechanism rather than run it, the source directory is the entire story, and this article does not pretend otherwise.

What the README does cover well is support and media. The header links to a YouTube channel, a Telegram channel at t.me/avencoresyt which is also the repository's recorded homepage, a VK group, and a Dzen channel. There is an installation and troubleshooting video guide, published across five platforms: YouTube, Rutube, Dzen, VK Video and Telegram. Given that the project targets users in a specific region and that its central problem is a regional check, hosting the guide on Russian platforms as well as YouTube is a deliberate reach decision rather than an incidental one.

The `source/` layout is also the practical answer to the question of whether this is a library. It is not importable code. The topics list `nuitka` and `pyinstaller`, both of which compile a Python program into a standalone executable, and the release artifacts are named `.exe` for Windows and bare filenames for Linux and macOS. So the pipeline is Python source compiled per platform, with `source/` as the input and the five binaries as the output. Contributors need a Python toolchain and one of those two compilers; end users need only the artifact for their platform.

On activity, the last commit to main was on 2026-09-06, the day after V1.3.6 shipped on 2026-09-05. The three most recent releases land at roughly two-week intervals, and the open issue count on the repository is zero, which for a project of this size and this rate of platform-specific bug reports is worth verifying against the issue tracker rather than taking as a sign of anything.

Editorial conclusion

The engineering in this repository is worth reading even if you never run it, because the release process is more disciplined than the subject matter suggests: five platform binaries per tag, a VirusTotal link for each artifact, a linked CI run, a numbered changelog line, and a POSIX-specific fix for safe file replacement in V1.3.5. What the tool cannot do is stated just as plainly. It modifies local files only, so Google's own licensing response is untouched, and the README says twice that a paid subscription or a supported-region account is the answer when you hit a 403 or a 500. That boundary also decides who should install it and who should not. A user whose account is already entitled has nothing to gain, because the patch targets regional checks rather than entitlements, and a developer whose employer holds a Google agreement has a terms question to settle before touching vendor files at all. Read the `source/` directory before forming a view, since the code itself is the one thing the repository does not summarise, and the last commit was on 2026-09-06 with V1.3.6 published the day before.

Frequently asked questions

Official sources

1. AvenCores/open-antigravity-patcher on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases