[Bug] Antigravity 429 RESOURCE_EXHAUSTED on any model (Claude Opus 4.6 / Sonnet 4.6 / Gemini 3.8 Flash) via EasyCLIProxyAPI v7.2.158 - quota OK, works in Antigravity App, fails via Opencode/OMP

[johngbl]

Is it a request payload issue?
[ ] Yes, this is a request payload issue. I am using a client/cURL to send a request payload, but I received an unexpected error.
[x] No, it's another issue.

Describe the bug
Getting HTTP 429 RESOURCE_EXHAUSTED with ANY model when using Antigravity auth through EasyCLIProxyAPI via Opencode and OMP. Same accounts work fine directly in the official Antigravity app.

Full error:

{
  "error": {
    "code": 429,
    "message": "Resource has been exhausted (e.g. check quota).",
    "status": "RESOURCE_EXHAUSTED"
  }
}

Tested models failing with same 429:

• Claude Opus 4.6
• Claude Sonnet 4.6
• Gemini 3.8 Flash
• All other Antigravity models also fail

Works fine if I use same account + same model directly in Antigravity App. Only fails via EasyCLIProxyAPI proxy.

Versions - both latest:

• Desktop Application: v0.2.88 / Latest v0.2.88
• Proxy Core Kernel: v7.2.158 / Latest v7.2.158

CLI Type
antigravity

Model Name
Claude Opus 4.6, Claude Sonnet 4.6, Gemini 3.8 Flash - happens with ANY Antigravity model

LLM Client
Opencode and OMP (using OpenAI-compatible endpoint from CLIProxyAPI)

Request Information
I enabled request-log: true in config.yaml and reproduced. Log attached.

Expected behavior
Should proxy any Antigravity model without 429 when quota is OK, same as Antigravity App does.

Screenshots

• Version screenshot: Desktop v0.2.88 / Core v7.2.158
• Models screenshot: Claude Opus 4.6, Claude Sonnet 4.6, Gemini 3.8 Flash

OS Type

• OS: Windows 11
• Desktop: v0.2.88
• Core: v7.2.158

Additional context

• Windows 11 + EasyCLIProxyAPI v0.2.88 + Core v7.2.158 latest
• Client: Opencode + OMP
• Any model from Antigravity list triggers 429 via proxy, but same model works in Antigravity App
• Quota normal
• Tried restart + antigravity-login
• Related to Antigravity auth still gets selected after 429 quota cooldown is already set #2831, Antigravity Accounts Rate Limited (HTTP 429) Despite Available Quota #1015, fix v6.6.89

[arksdev]

Same symptom here, with a data point that may help narrow it down.

Setup: CLIProxyAPI on a remote server (commit 5b27856, includes v7.2.158), single Antigravity OAuth account, client is a third-party OpenAI-compatible agent (OMP). Model: gemini-3.8-flash-high.

Observation 1 — size-dependent: a tiny probe (Reply with exactly: ..., <50 input tokens) through the proxy returns completed. A 227 KB request (large system prompt, same model, same account) returns upstream 429 RESOURCE_EXHAUSTED. Both requests succeed when sent directly through the official Antigravity app on the same account.

Observation 2 — retries amplify: with default request-retry: 3, the 227K-token request was re-sent 3 more times within ~30 s (~1M input tokens into one quota bucket), sustaining the 429 and growing the credential cooldown 3s → 31s → 60s. Setting request-retry: 0 stopped the amplification; after the cooldown expired the small probe passed again.

So at least in our case the proxy is not hitting a hard block — it looks like the proxy's upstream call lands in a tighter quota bucket than the app's (consistent with #1015's quota-API-vs-generate mismatch), and the retry loop then turns a transient hit into a persistent one.

[arksdev]

Update with the actual root cause — it is not quota.

A bisect in oh-my-pi (can1357/oh-my-pi#11699) shows Google's Cloud Code Assist endpoint recently enabled an abuse/WAF rule that flags the literal block

<system-conventions>
RFC 2119: MUST, REQUIRED, SHOULD, RECOMMENDED, MAY, OPTIONAL.

when present in systemInstruction. The gateway rejects the stream with a false HTTP 429 RESOURCE_EXHAUSTED instead of a 400. Swapping just the tag to <system_conventions> (rest of a 62 KB payload untouched) immediately returns HTTP 200.

This explains my size-dependent observation exactly: my tiny probe that passed carried a plain-text input with no system prompt, while the failing 227 KB request came from an OMP client whose hardcoded system prompt starts with <system-conventions> (verified in packages/coding-agent/src/prompts/system/system-prompt.md:1). Same account, same model — the only difference is the tag. The official Antigravity app works because its prompt has no such tag.

So for Antigravity 429s via this proxy, the first thing to check is whether the client sends <system-conventions>. Related upstream: can1357/oh-my-pi#11699 (open, root cause), #11693 (closed, misclassification fix), #11704, #11689.

My earlier retry-amplification point stands independently: with a single auth entry, request-retry: 3 on 429 re-sends the full payload into the same bucket, so it is still worth disabling until multiple accounts exist — but retries were an amplifier here, not the cause.

[arksdev]

Server-side workaround that fixes this for all clients at once (verified live just now).

CLIProxyAPI already ships a hook for exactly this: antigravity.sensitive-words in config — words that get zero-width-space obfuscation inside systemInstruction/system/message content before the request leaves the proxy (antigravity_executor*.go → obfuscateSensitiveWords, all paths: execute, stream, tokens). The obfuscation breaks the WAF's literal match while remaining invisible to the model.

antigravity:
  sensitive-words:
    - "system-conventions"
    - "system_conventions"
    - "system-directive"
    - "system_directive"

After restart, a request carrying the literal <system-conventions> + RFC 2119 block in instructions returns status: completed through the proxy instead of 429. No client changes, no per-machine sidecars.

Caveat: this is obfuscation, not a rename — if Google's rule ever matches fuzzily (e.g. normalized or embedding-based), it stops working. A config-native rename/mask option for known-flagged harness tags would be the durable version of this. Happy to open a feature request if you point at the right place.

[Zessi-C]

Independent reproduction from OMP 18.1.18:

• Route: OpenAI-compatible POST /v1/chat/completions
• Model: gemini-3.8-flash-high
• Same CPA endpoint, credential, model, and user message for all tests

A neutral request returns HTTP 200. The following minimal system content returns HTTP 429 RESOURCE_EXHAUSTED:

<system-conventions>
RFC 2119: MUST, REQUIRED, SHOULD, RECOMMENDED, MAY, OPTIONAL.

Additional bisection results:

• The RFC line without <system-conventions> returns 200.
• The same RFC line under <foo> returns 200.
• The <system-conventions> line plus a truncated RFC list ending at MAY returns 200.
• The exact list ending in OPTIONAL. returns 429.
• The closing </system-conventions> tag and the following NEVER/AVOID text are not required.

The actual OMP payload was approximately 61 KB with 11 tools. It returned 429. Keeping the full payload unchanged except for inserting a zero-width character into RFC returned HTTP 200. Running OMP through an equivalent request-rewrite layer produced OK end-to-end.

A narrow server-side workaround is therefore sufficient:

antigravity:
  sensitive-words:
    - 'RFC 2119: MUST, REQUIRED, SHOULD, RECOMMENDED, MAY, OPTIONAL.'

This appears to be a literal/token-level upstream WAF or abuse-rule match in systemInstruction, not quota exhaustion. The HTTP 429 is misleading. The trigger is distinct from the Hermes/Nous identity phrase in #4696.

It would be useful to document this known pattern, apply a scoped default workaround for Antigravity, or return a more accurate error category. No credentials or private endpoint details are included here.

[YJ2CS]

Thanks a lot!

OMP 18.1.18 的独立复制：

• 路由：兼容OpenAIPOST /v1/chat/completions
• 模型：gemini-3.8-flash-high
• 所有测试都使用相同的CPA端点、凭证、型号和用户消息

中性请求返回 HTTP 200。以下最小系统内容返回HTTP 429：RESOURCE_EXHAUSTED

<system-conventions>
RFC 2119: MUST, REQUIRED, SHOULD, RECOMMENDED, MAY, OPTIONAL.

其他二分结果：

• RFC行（不含返回）200。<system-conventions>
• 同一行RFC代码低于返回200。<foo>
• 该行加上一个截断的RFC列表，最终返回200。<system-conventions>``MAY
• 准确的列表以429号结束。OPTIONAL.
• 关闭标签和以下内容/文本不是必需的。</system-conventions>``NEVER``AVOID

实际OMP有效载荷约为61 KB，配备11个工具。结果为429。保持完整有效载荷不变，仅在返回的HTTP 200中插入零宽度字符。通过等效的请求-重写层运行OMP实现端到端。RFC``OK

因此，一个狭窄的服务器端变通方法就足够了：

antigravity:
sensitive-words:
- 'RFC 2119: MUST, REQUIRED, SHOULD, RECOMMENDED, MAY, OPTIONAL.'
这似乎是字面/令牌级别的上游WAF或滥用规则匹配，而不是配额耗尽。HTTP 429具有误导性。触发点与#4696中的赫尔墨斯/诺斯身份短语不同。systemInstruction

记录这一已知模式、应用反重力的带范围默认变通方法，或返回更准确的错误类别会很有用。这里不包含凭证或私有端点信息。

Thank you so much! Thanks for the solution provided in this issue—I thought my home IP address was flagged by risk control. After configuring sensitive-words as suggested above, everything is back to normal.

[yangjijian2121]

Landing here from the same 429: what clears it is antigravity.sensitive-words (v7.2.118+). For the oh-my-pi / omp fingerprint the whole set is:

antigravity:
  sensitive-words: ["RFC 2119", "system-conventions", "system_conventions", "system-directive", "system_directive"]

The reason this costs so much time to find is that the failure looks like quota: the upstream body says Resource has been exhausted (e.g. check quota). while the credential's quota is untouched, the call is then classified as a rate-limit hit, and what an operator actually sees next is All credentials for model ... are cooling down via provider antigravity — which points at quota, credential rotation, or risk control rather than at request content.

#5790 (diagnostic only — no payload change, no retry/cooldown change) makes the proxy say so itself: it warns with the matched phrase when one still leaves unmasked, and antigravity.false-429-phrases overrides or disables that list for deployments tracking a different rule.

[xiaoxinglgm]

I reproduced the same misleading 429 with a Codex client and narrowed it down to another system-instruction fingerprint.

Environment:

• CLIProxyAPI v7.2.129
• OpenAI-compatible /v1/responses
• Antigravity OAuth provider
• Model: gemini-3.8-flash-high

Controlled A/B results:

• You are a helpful coding assistant. -> HTTP 200
• You are Codex. -> HTTP 200
• You are an agent based on GPT-5. -> HTTP 200
• You are Codex, an agent based on GPT-5. -> HTTP 429 RESOURCE_EXHAUSTED
• The same combined sentence with a zero-width character inserted into Codex -> HTTP 200

The failing error log showed the upstream request going to cloudcode-pa.googleapis.com/v1internal:streamGenerateContent, and retries reached API request 6 before the proxy returned 429. A tiny neutral request succeeded using the same Antigravity credential, so this was not actual quota exhaustion.

The following server-side configuration fixed it:

antigravity:
  sensitive-words:
    - Codex

After hot reload, both the minimal triggering sentence and the full Codex system instruction returned HTTP 200. The full system-instruction test request was about 18 KB. No client-side change was required.

[AsesLoL]

CLIProxyAPI version: 7.3.3 (core, standalone binary, Windows amd64)
Auth channel: antigravity (--antigravity-login)

Summary

All Antigravity models return 429 RESOURCE_EXHAUSTED on the very first request, immediately after a fresh OAuth login — reproduced on two separate, unrelated Google accounts, which rules out per-account quota exhaustion. Same pattern as #910, #5751 and #1015.

Reproduction

1. cli-proxy-api.exe --antigravity-login --config config.yaml — fresh login, account A. Login succeeds, project_id obtained (aicode-consumers).
2. First request to /v1/messages, model aliased to gemini-3.8-flash-high → immediate 429:

   { "error": { "code": 429, "message": "Resource has been exhausted (e.g. check quota).", "status": "RESOURCE_EXHAUSTED" } }

3. Retried with lighter models on the same account: gemini-3.1-flash-lite, gemini-pro-agent — same error, same account-wide cooldown (not model-specific).
4. Removed account A's credential file, logged in fresh with a second, unrelated Google account (account B) — same project_id (aicode-consumers), same instant 429 on the very first request, across the same set of models.
5. Elapsed time from OAuth success to first request, both times: well under a minute — not plausibly explained by prior usage on either account.

Notes

• project_id / cloudaicompanionProject resolves fine both times (not the missing-project_id failure mode discussed in Antigravity Accounts Rate Limited (HTTP 429) Despite Available Quota #1015).
• Both accounts show "project": "aicode-consumers" in the upstream request — same shared project identifier other users are reporting.
• Codex (OpenAI) OAuth channel on the same install works normally, including with 2 rotating accounts (round-robin). This looks specific to the Antigravity channel/backend, not a client-side proxy bug.

Adding this as another reproducible data point (2 accounts, fresh logins, timestamps in hand) — happy to share full debug logs if useful.