google-antigravity/antigravity-cli

i barely sent a message and it exhausted my limit...

Codex has basically the same usage limits as Antigravity CLI but at least it is transparent about it

So either switch to Codex or use Gemini CLI with AI Studio key

Update: when I used Gemini 3.5 Flash (Medium), it ate my weekly quota in one relatively simple task

To put the gemini-cli limits into perspective, imagine loading 950k tokens of context files and asking the model a question. You could have done that on nearly a million tokens of context 1000 times!!! 1,000 milions input tokens!

+1 for ACP support I currently use Gemini CLI ACP and Codex App Server as part of a human in the loop Claude Code Opus orchestration multi-agent bridge. AGY CLI not supporting it means reverting to a print bridge which will still work for code reviews but seriously limit any longer running jobs by not providing feedback.

I'm on Android/Termux and hit the same issue

I got it fully working natively on Termux , no proot-distro, no VM, no Cloud Shell. The fix required addressing 7 separate issues: VA39 TCMalloc patch, `faccessat2` syscall rewrite, glibc `libc.so` shim, `LD_PRELOAD` pollution, DNS resolver, TLS certificates, and shell hash caching.

The `faccessat2` fix is not in @hjotha 's patch, Android seccomp blocks it with `SIGSYS` after the TCMalloc issue is resolved, so both patches are needed together.

Full writeup with reusable patch script: https://gist.github.com/Brajesh2022/e42160d29b55417db6c18c52dd1d6d37

The script is pattern-based, not offset-based, so it should work across versions. You can also paste the gist URL or its full contents directly into any AI agent and ask it to set up your environment , the document has enough detail to follow without human guidance.

On macOS, you must press Ctrl+V to paste an image. I believe it should use Cmd+V instead.

+1 from a GDE perspective.

Concrete signal beyond the general ecosystem argument:
- I run a dual-engine workflow (Claude + Gemini) across ~10 machines
via Tailscale, using ACP brokers (OpenAB-style) to bridge them into
Discord/Telegram for mobile/remote use. `gemini --acp` is currently
the Gemini side of this; `agy --acp` would let it survive the 6/18
gemini-cli sunset without code changes on the orchestrator side.
- Re: sbinnee's correction — agreed, `claude --acp` is via
@zed-industries/claude-code-acp not native, and `codex acp` is via
Zed similarly. But the user experience is the same: a single
`--acp` invocation point. Whether agy ships it natively or Google
publishes an `@google/agy-acp` adapter, either resolves the
orchestrator integration gap.
Happy to test a beta if/when there's something to try.

I'm adding to this thread for visibility. I'm trying to migrate from Gemini CLI to Antigravity CLI. But I got the same error:

```
FATAL ERROR: This binary was compiled with aes enabled, but this feature is not available on this processor (go/sigill-fail-fast).
bash: line 237: 50341 Illegal instruction "$BINARY_PATH" install

```

No AES on my old CPU where I run the CLI: Intel Core i3 3240

+1 for acp support.

Currently I use the acp clients to develop projects in the background, this is crucial for it to work

I'm running into the exact same issue as the user with the i3-3210 above, but on an **Intel Core i5-3210M** (older Samsung laptop) running Ubuntu Server 26.04 LTS.

In my case, the CPU physically supports AES-NI, but the manufacturer permanently locked the feature in the BIOS. As a result, the OS can never see the `aes` flag, making it impossible to bypass on my end.

I get the exact same crash during installation:

```bash
FATAL ERROR: This binary was compiled with aes enabled, but this feature is not available on this processor (go/sigill-fail-fast).
bash: line 237: 2049 Illegal instruction "$BINARY_PATH" install

```

Just wanted to add my use case to highlight that this strict hardware requirement is locking out valid `linux_amd64` machines, not just older ARM boards.

I was running the **Gemini CLI** on this exact same setup without any problems, as it didn't enforce this baseline. It would be great if the team could provide a baseline compatibility build (e.g., compiled w...

Absence of ACP in antigravity-cli means [agent-shell ](https://github.com/xenodium/agent-shell) won't have a gemini option after gemini-cli is deprecated.

Agent-shell is an agent-agnostic front-end to tools like gemini-cli and claude code designed to make terminal based code assist tools easier to use in emacs. There are a lot of issues with running antigravity-cli/claude code/gemini-cli directly in vterm in emacs.

Yes. that's easy enough to do.

On Wed, May 20, 2026 at 4:29 PM Henrique Jotha ***@***.***>
wrote:

> *hjotha* left a comment (google-antigravity/antigravity-cli#64)
>
>
> @MichaelWS yes, with the caveats above.
>
> I validated it on my GT-BE98 running a 39-bit ARM64 userspace VA kernel.
> With the VA39-patched agy.native-arm64 plus the ptrace shim and explicit
> glibc loader, both of these worked:
>
> /mnt/routerdisk/agy --version
> # 1.0.0
>
> /mnt/routerdisk/agy --help
> # exits 0 and prints help
>
> The important detail is that there are two separate issues:
>
> - The ptrace shim handles missing ARM64 instructions on this older
> router CPU.
> - The TCMalloc startup abort is separate and requires the binary
> itself to use the 39-bit address/tag layout. A partial patch that only
> changes RandomMmapHint() gets past the fi...

@MichaelWS yes, with the caveats above.

I validated it on my GT-BE98 running a 39-bit ARM64 userspace VA kernel. With the VA39-patched `agy.native-arm64` plus the ptrace shim and explicit glibc loader, both of these worked:

```text
/mnt/routerdisk/agy --version
# 1.0.0

/mnt/routerdisk/agy --help
# exits 0 and prints help
```

The important detail is that there are two separate issues:

- The ptrace shim handles missing ARM64 instructions on this older router CPU.
- The TCMalloc startup abort is separate and requires the binary itself to use the 39-bit address/tag layout. A partial patch that only changes `RandomMmapHint()` gets past the first mmap failure, but later fails in fast deallocation/tag checks. The tag/deallocation masks also have to move from the 48-bit/bit-42 layout to the 39-bit/bit-35 layout.

So yes, the patch works for the exact `agy.native-arm64` SHA I listed, but I would treat it only as validation of the root cause, not as a stable downstream workaround. The real ...