how to use proxy (antigravity-manager) in openclaw | Friends of the Crustacean 🦞🤝 | Page 1

quasi nova Mar 10, 2026, 4:29 AM

#

I tried "openclaw configure" with "custom provider" option BASE_URL = http://127.0.0.1:8045/v1 and API_KEY but console display "fetch failed"

glossy eagleBOT Mar 10, 2026, 4:29 AM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

jolly basinBOT Mar 10, 2026, 4:33 AM

#

TypeError: fetch failed in the custom provider step almost always means OpenClaw couldn’t reach that URL at all (connection refused / timeout / DNS / wrong network namespace), not that your API key was “wrong”.

A quick checklist:

Version + topology (first)

What’s your openclaw --version?
Are you running OpenClaw on the same machine as antigravity-manager?
- If your Gateway is on a VPS / Docker / WSL, then 127.0.0.1 points to that environment, not your host machine.

Confirm the proxy is actually reachable from where you ran openclaw configure
Run this on the same box/environment where you ran openclaw configure:

curl -v http://127.0.0.1:8045/v1/models

If this can’t connect → fix the proxy bind/port first (or use the correct host/IP).

#

If this connects but returns 404/HTML/etc → your proxy probably isn’t OpenAI-compatible on that path (wrong base path), or it doesn’t implement /v1/models (the wizard may probe it).

If OpenClaw is in Docker/WSL/remote

Docker: 127.0.0.1 is the container. You typically want http://host.docker.internal:8045/v1 (or run with host networking).
Remote Gateway: you need a base URL reachable from the Gateway host (LAN IP, Tailscale, reverse proxy), not localhost on your laptop.

Get the real error cause from logs
Right after it fails:

openclaw logs --follow

That usually shows the underlying cause (e.g. ECONNREFUSED 127.0.0.1:8045).

If you paste:

openclaw --version

#

the output of curl -v http://127.0.0.1:8045/v1/models
and whether you’re on Docker/WSL/VPS/local

…I can tell you exactly which of the above cases you’re hitting.

Docs reference for how custom providers are supposed to look: https://docs.openclaw.ai/gateway/configuration-reference#custom-providers-and-base-urls

quasi nova Mar 10, 2026, 4:34 AM

#

hmm, antigravity-manager in window, openclaw in wsl, i think it's problem

jolly basinBOT Mar 10, 2026, 4:35 AM

#

Yep — that’s almost certainly it.

In WSL2, 127.0.0.1 means “inside the Linux VM”, not your Windows host. So OpenClaw in WSL is trying to connect to a server that doesn’t exist (→ fetch failed).

Fix: point OpenClaw (WSL) at the Windows host IP

From WSL, get the Windows-host/gateway IP (usually the default route):

WIN_HOST=$(ip route | awk '/default/ {print $3}')
echo $WIN_HOST
curl -v "http://$WIN_HOST:8045/v1/models"

If that curl works, use this as your custom provider base URL:

#

http://<WIN_HOST>:8045/v1

If `curl` still fails…

Then antigravity-manager on Windows is probably only bound to 127.0.0.1 (Windows loopback). In that case WSL can’t reach it via the host IP.

You’ll need to change antigravity-manager to listen on 0.0.0.0 (or the “vEthernet (WSL)” interface), and make sure Windows Firewall allows inbound on port 8045 from the WSL network.

If you paste the output of:

curl -v "http://$(ip route | awk '/default/ {print $3}'):8045/v1/models"

…I can tell you which case you’re in (not listening vs firewall vs wrong path).

jolly basinBOT Mar 10, 2026, 6:31 AM

#

If curl -v prints a line like * Trying <ip>:8045... and then just hangs, that means WSL can’t complete the TCP connection to Windows on that port (most commonly: Windows firewall drop, or the service is only listening on 127.0.0.1).

Try these in order:

1) First, see if Windows “localhost forwarding” works

In WSL:

curl -v --connect-timeout 2 http://localhost:8045/v1/models

If that works, you can keep using http://localhost:8045/v1 as the base URL.

2) Confirm what `$WIN_HOST` actually is

WIN_HOST=$(ip route | awk '/default/ {print $3}')

#

echo "WIN_HOST=$WIN_HOST"
curl -v --connect-timeout 2 "http://$WIN_HOST:8045/v1/models"

3) On Windows: check what address antigravity-manager is listening on

In PowerShell (Windows):

netstat -ano | findstr :8045

If you see it listening on 127.0.0.1:8045 only → WSL won’t be able to reach it via $WIN_HOST. You need to configure antigravity-manager to bind to 0.0.0.0 (or the “vEthernet (WSL)” interface), or use a port-proxy.
If you see 0.0.0.0:8045 (or your machine IP) → it’s listening, so the hang is almost certainly Windows Firewall. Add an inbound rule allowing TCP 8045 on Private networks (at least for vEthernet (WSL)).

If you paste the full output of the WSL curl -v --connect-timeout 2 ... (including the Trying ... line), I can tell you whether it’s “connection refused” vs “timeout” and what to fix next.

quasi nova Mar 10, 2026, 6:37 AM

#

Connected to 172.26.112.1 (172.26.112.1) port 8045

GET /v1/models HTTP/1.1
Host: 172.26.112.1:8045
User-Agent: curl/8.5.0
Accept: /

< HTTP/1.1 401 Unauthorized
< vary: origin, access-control-request-method, access-control-request-headers
< access-control-allow-origin: *
< content-length: 0
< date: Tue, 10 Mar 2026 06:35:48 GMT
<

Connection #0 to host 172.26.112.1 left intact

jolly basinBOT Mar 10, 2026, 6:39 AM

#

Nice — that output is actually progress:

Network path WSL → Windows works (it connected to 172.26.112.1:8045)
The proxy is responding, but it’s returning 401 Unauthorized
So the remaining problem is authentication/header, not connectivity.

1) Figure out what header antigravity-manager expects

From WSL, try /v1/models again but with an auth header:

OpenAI-style (most common):

curl -v -H "Authorization: Bearer YOUR_API_KEY" http://172.26.112.1:8045/v1/models

If that still gives 401, try Anthropic-style:

#

curl -v -H "x-api-key: YOUR_API_KEY" http://172.26.112.1:8045/v1/models

Whichever one returns 200 + JSON is the one OpenClaw needs to send.

2) In `openclaw configure`, make sure you’re giving the real key

Common gotcha: in the wizard, people accidentally enter the env var name (like API_KEY) instead of the actual key value, or they choose “secret reference” but didn’t export the env var.

If your curl works with Authorization: Bearer ..., then in OpenClaw the custom provider should also be able to work with:

baseUrl: http://172.26.112.1:8045/v1
the same API key value

3) If antigravity-manager needs a non-standard header

OpenClaw can do it via models.providers.<id>.headers in config (manual config), but first we need to know which header works from the curl tests above.

Paste the result of the Bearer curl (just the status line + any response body), and I’ll tell you exactly which option to pick in the wizard (or what config snippet to use).

quasi nova Mar 10, 2026, 6:49 AM

#

u're so kind

#

thanks

#

🎉

jolly basinBOT Mar 10, 2026, 6:49 AM

#

All good — paste the output of the two curl tests (Authorization: Bearer ... and/or x-api-key: ...) and we’ll translate that into the exact OpenClaw custom-provider settings so openclaw configure stops failing.

#

No problem. If you hit another error (or if openclaw configure still says fetch failed), drop the curl output with the auth header and we’ll pin down the exact header/config OpenClaw needs.

#

Glad it’s working.

If this fixed it, please right-click the solution message → Apps → Mark Solution so Answer Overflow can index it for the next person.

quasi nova Mar 10, 2026, 6:59 AM

#

I tried send a prompt but logs is api rate limit, Idk if prompt was sent to antigravity model, how to check

jolly basinBOT Mar 10, 2026, 7:00 AM

#

If the logs say rate limit / HTTP 429 from your antigravity custom provider, then yes: OpenClaw did send the request to that upstream (the upstream rejected it before generating a response, but the prompt left your machine).

How to confirm exactly what happened (and whether it fell back to something else):

Check what model(s) OpenClaw is configured to use

openclaw models status

This shows your primary model and any fallbacks. If you have fallbacks configured, a rate limit can cause OpenClaw to retry the same prompt on the next model/provider.

Watch the live logs while you send a test prompt

openclaw logs --follow

Send one short prompt, then look for the log lines around that timestamp — you should see the provider/model it tried and the 429.

Be careful with --probe

#

openclaw models status --probe can show live auth/provider info, but it makes real requests (so it can also trigger rate limits).

If you paste the exact rate limit log line(s) (redact keys), I can tell you whether it only hit antigravity or also attempted fallbacks. Also: what’s your openclaw --version?

quasi nova Mar 10, 2026, 7:08 AM

#

i dont see any request in traffic logs in antigravity manager

jolly basinBOT Mar 10, 2026, 7:10 AM

#

If antigravity-manager shows zero traffic, then OpenClaw is almost certainly not using your custom provider for that prompt (the “rate limit” you saw is coming from some other provider/model it tried).

Two fast ways to verify:

1) Check what model OpenClaw is actually using

Run:

openclaw models status

Look for the Default model (primary + fallbacks). If it doesn’t show your custom provider (<yourProviderId>/<yourModelId>), then prompts won’t hit antigravity-manager.

If you do see your custom provider there, paste the models status output (it’s safe; keys are redacted) and we’ll spot what’s off.

2) Look at the rate limit log line and see which provider it mentions

In the gateway logs (openclaw logs --follow), the error line usually includes the provider/model it was calling. Paste that one line.

#

Common gotcha

Even after configuring a custom provider, you still need to set the default model to it, e.g.:

openclaw models set <providerId>/<modelId>

(You can find the exact <providerId>/<modelId> via openclaw models list.)

Docs: https://docs.openclaw.ai/cli/models and https://docs.openclaw.ai/concepts/model-failover

quasi nova Mar 10, 2026, 7:11 AM

#

status -probe
custom-172-26-112-1-8045/gemini-3-flash │ models.json (api_key) │ ok · 2.3s

jolly basinBOT Mar 10, 2026, 7:12 AM

#

That models status --probe line is great news: OpenClaw can reach your custom provider and authenticate successfully.

If you still don’t see prompt traffic in antigravity-manager, the usual cause is: your current Discord session is still pinned to an older model (model changes don’t always take effect mid-session).

Do this in the Discord chat/thread with the bot:

Start a fresh session:

/new (or /reset)

Explicitly pin the model for that session:

/model custom-172-26-112-1-8045/gemini-3-flash

Send a short prompt, and at the same time run:

openclaw logs --follow

#

In the logs you should see it calling custom-172-26-112-1-8045/gemini-3-flash. If you paste that log snippet (and/or the “rate limit” line), we can confirm whether it’s actually hitting the proxy or failing over to something else.

quasi nova Mar 10, 2026, 7:17 AM

#

00 {
"error": {
"code": 400,
"message": "Built-in tools ({google_search}) and Custom tools (Function Calling) cannot be combined in the same request. Please choose one to continue.",
"status": "INVALID_ARGUMENT"
}
}

jolly basinBOT Mar 10, 2026, 7:19 AM

#

That 400 is a Gemini API limitation, and the wording is basically saying:

Built-in tool = Gemini’s own google_search
Custom tools = function calling / tool definitions (which OpenClaw uses for its tools)

Gemini rejects requests that include both in the same call.

So what’s happening is: somewhere between OpenClaw → antigravity-manager → Gemini, the request ends up containing google_search + function calling, and Gemini hard-fails with INVALID_ARGUMENT.

What you can do

Option A (best): Disable `google_search` in antigravity-manager

If antigravity-manager has a setting like “grounding/search on/off” / “google_search tool”, turn it off. Then OpenClaw tool-calling can work normally.

Option B (workaround): Disable tool-calling in OpenClaw just for that model

This makes OpenClaw stop sending function-calling tool definitions, so Gemini can keep google_search without conflict.

#

In ~/.openclaw/openclaw.json:

{
  tools: {
    byProvider: {
      "custom-172-26-112-1-8045/gemini-3-flash": { profile: "minimal" }
    }
  }
}

Then restart:

openclaw gateway restart

#

Downside: that model becomes “chat only” (no agent tools).

If you tell me whether antigravity-manager has an option to disable “google_search/grounding”, I can point you at the cleanest path. Also: what openclaw --version are you on?

quasi nova Mar 10, 2026, 7:24 AM

#

low context window: custom-172-26-112-1-8045/gemini-3-flash ctx=16000 (warn<32000) source=modelsConfig

how to increase context, gem 3 flasg up to 1m

jolly basinBOT Mar 10, 2026, 7:25 AM

#

That warning tells you exactly what’s happening:

ctx=16000 … source=modelsConfig = OpenClaw’s model catalog entry for custom-172-26-112-1-8045/gemini-3-flash currently says the context window is 16k, so OpenClaw will start truncating/compacting as if it’s a 16k model.

To increase it, you need to override the model metadata for that custom provider/model and set a bigger contextWindow.

Option 1 (most direct): edit the agent’s `models.json` (since `source=modelsConfig`)

Find where that provider is defined:

rg -n "custom-172-26-112-1-8045|gemini-3-flash" ~/.openclaw/agents/*/agent/models.json

Then edit the matching model entry and set e.g.:

contextWindow: 1000000 (Gemini 3 Flash “1M”)
optionally maxTokens: 8192 (or whatever your proxy supports for output)

#

Example shape:

{
  models: {
    providers: {
      "custom-172-26-112-1-8045": {
        models: [
          {
            id: "gemini-3-flash",
            contextWindow: 1000000,
            maxTokens: 8192,
          },
        ],
      },
    },

#

  },
}

Then restart:

openclaw gateway restart

Option 2: override via `~/.openclaw/openclaw.json` (`models.providers…`)

You can also add/override the same provider/model under models.providers in your main config (OpenClaw will take the higher contextWindow when merging).

After restarting, re-check:

#how to use proxy (antigravity-manager) in openclaw