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.

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.

Same on my Lenovo 14

```
mdfranz@lenovo-cr14p-arm:~/.local/bin$ ldd agy
linux-vdso.so.1 (0x0000007f90eca000)
libresolv.so.2 => /lib/aarch64-linux-gnu/libresolv.so.2 (0x0000007f90e50000)
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007f90e20000)
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007f90d70000)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007f90d40000)
librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000007f90d10000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f83050000)
/lib/ld-linux-aarch64.so.1 (0x0000007f90e80000)
mdfranz@lenovo-cr14p-arm:~/.local/bin$ ./agy
4344 third_party/tcmalloc/internal/system_allocator.h:595] MmapAligned() failed - unable to allocate with tag (hint=0x2ffcc0000000, size=1073741824, alignment=1073741824) - is something limiting address placement?
4344 third_party/tcmalloc/internal/system_allocator.h:602] Note: the allocation may have ...

+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 believe this is a duplicate of #8

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...