Antigravity: Opus 4.6

[tawny silo]

The model picker/list isn’t a guarantee that Antigravity OAuth can actually run it — it’s basically a catalog entry. Antigravity model availability is controlled on their side, and it’s pretty common for a new Claude model to show up in lists before it’s actually enabled (you’ll get a “model not found” / “permission” style error when you try to use it).

To confirm what’s going on, can you paste:

1. the exact model ref you’re selecting (the full provider/model, not just “opus 4.6”), and
2. the output of /model status (or openclaw models status), plus
3. openclaw --version

If you want the most up-to-date “is it enabled right now” answer, #models is usually where people confirm these rollouts fastest, since it changes without a code release.

Docs reference (Antigravity auth flow): https://docs.openclaw.ai/concepts/model-providers#google-vertex-antigravity-and-gemini-cli

That line just means OpenClaw is willing to try google-antigravity/claude-opus-4-6 (i.e., it’s in your configured/allowed model set and parsed correctly). It doesn’t guarantee Antigravity OAuth has access enabled for that model yet.

Fastest way to answer “is it actually available for you right now”:

• Send a tiny prompt using that default model (anything like “ping”).
  • If it replies → yes, it’s live for your Antigravity account.
  • If you get an API error like model not found / permission denied / 404 → it’s showing in the catalog but not enabled yet (or not enabled for your tier/account).

If you paste the exact error text (and ideally /model status + openclaw --version), I can tell you whether it’s:

• an Antigravity-side availability/gating issue, or
• an OpenClaw config/allowlist/auth issue.

(Also: it’s normal for new models to appear in /model list before rollout is fully open.)

[fierce sphinx]

claude code assist api error 404 requested entity not found. but i believe it should be enabled

[tawny silo]

That 404 (“requested entity not found”) is coming from the Cloud Code Assist / Antigravity endpoint, and it almost always means the model ID you requested doesn’t exist on that endpoint (yet), or isn’t enabled for your account/tier.

One important gotcha with Antigravity + Claude models: the working refs have typically been the …-thinking variants (example from OpenClaw’s own live-test matrix: google-antigravity/claude-opus-4-5-thinking), not the plain claude-opus-4-x. So if you’re trying:

• google-antigravity/claude-opus-4-6 → 404

…try selecting the Antigravity Claude model that ends in -thinking from /model list (e.g. if you see google-antigravity/claude-opus-4-6-thinking, use that).

If you don’t see a -thinking option, paste:

• /model list (the antigravity section) or openclaw models list --all --provider google-antigravity --plain
• openclaw --version

…and we can tell whether you’re on an older catalog build / wrong model ref, vs Antigravity rollout/account gating.

Yeah, that list explains the 404.

For Antigravity, the Claude models that actually exist on the backend have (so far) typically been the *-thinking IDs (like your working google-antigravity/claude-opus-4-5-thinking). Seeing google-antigravity/claude-opus-4-6 without a -thinking variant in the list is a strong hint the catalog entry is wrong / incomplete, and Antigravity is answering “that entity doesn’t exist” → 404.

Two concrete things to try:

1. Try the “likely real” model id manually (even though it’s not in the picker):

   • /model google-antigravity/claude-opus-4-6-thinking

   If that works: great — OpenClaw’s model catalog just needs to be updated to include it (and/or prefer it).

2. If …4-6-thinking still 404s, then it’s almost certainly not enabled (yet) for your Antigravity account/tier/region, even if some UI/model list shows it.

If you can paste:

• your openclaw --version
• the exact full error blob (the part that includes the endpoint/status/message)

…I can say with confidence whether it’s (a) missing model id in OpenClaw’s catalog vs (b) Antigravity rollout gating. If it’s (a), best next step is filing a bug on OpenClaw with that /model list output + the 404.

The “full error blob” will be in the Gateway logs (not just the one-line surface error).

On your Mac, easiest options:

1) Tail live logs and reproduce the error (best)

openclaw logs --follow

Then try the model again and copy the few lines around the failure.

If you want machine-readable (often includes the full HTTP error payload):

openclaw logs --follow --json

2) Quick pasteable debug bundle (includes log tail, redacts tokens)

openclaw status --all

3) Open the log file directly

Default file is:

• /tmp/openclaw/openclaw-YYYY-MM-DD.log

So e.g.

tail -200 /tmp/openclaw/openclaw-*.log

Docs: https://docs.openclaw.ai/logging

No — those lines are just the internal queue/diagnostic plumbing (“lane enqueue/dequeue”). They don’t include the provider HTTP response.

What you’re looking for is a log line that mentions something like:

• google-antigravity / cloudcode-pa.googleapis.com
• Cloud Code Assist API error
• HTTP 404 / requested entity was not found
• the endpoint (often /v1internal:streamGenerateContent?...)

Easiest way to capture it

1. Run:

openclaw logs --follow

2. In another terminal / in Discord, trigger the failure again (send a message while on the google-antigravity/claude-opus-4-6 model).

3. Copy/paste the few log lines around the actual error (you’ll see an error or warn line, not just debug diagnostic).

If the log stream is noisy, filter it

If you have ripgrep (rg):

openclaw logs --follow --plain | rg -i "antigravity|cloudcode|code assist|requested entity|404|streamGenerate"

If not, use grep:

openclaw logs --follow --plain | grep -iE "antigravity|cloudcode|code assist|requested entity|404|streamGenerate"

“Just give me something pasteable”

openclaw status --all

That’s usually the best single blob to share (includes a safe log tail and redacts secrets).

Paste whatever line includes the 404 + endpoint and we can tell if it’s “wrong model id” vs “not enabled on Antigravity yet”.

Nope — that debug diagnostic lane dequeue line still isn’t the provider error. It just means the gateway popped something off the internal queue.

What happened in your paste is: you grabbed a log tail that started around “google tool schema snapshot”, but the actual 404 line is further down and your tail got cut off (Log tail truncated).

Here are the two easiest ways to get the real 404:

Option A: pull a bigger log chunk

openclaw logs --plain --limit 2000 --max-bytes 2000000

Option B (best): follow logs, then reproduce the failure

openclaw logs --follow --plain --max-bytes 2000000

Then send a message while /model is set to google-antigravity/claude-opus-4-6 and copy the first line that contains:
Cloud Code Assist API error / HTTP 404 / requested entity was not found / cloudcode-pa.googleapis.com.

If it’s too noisy, filter it down

openclaw logs --follow --plain --max-bytes 2000000 \
  | grep -iE "antigravity|cloudcode|code assist|requested entity|404|stream"

Once you paste the actual 404 line (it usually includes the endpoint), we can confirm whether this is just the wrong model id (very likely: missing claude-opus-4-6-thinking) vs Antigravity not enabling it for your account yet.

Not yet — that line is still just the “we built a Google tool schema snapshot” info message. The actual 404 will be a separate warn/error line a bit later, but your log output got cut off (Log tail truncated).

Try re-grabbing a bigger chunk:

openclaw logs --limit 2000 --max-bytes 2000000 --plain

Or, best: follow logs while you reproduce the error:

openclaw logs --follow --max-bytes 2000000 --plain

If the output is too noisy, filter to just Antigravity / the 404: