Connect an Antigravity provider to 9Router

To use an Antigravity account as an upstream connection in 9Router, open its provider page, complete the account connection flow, then test an exposed model through the router. This is the direction covered below: a client calls 9Router, which uses the connected account. It does not configure the Antigravity IDE to call 9Router.

The current 9Router registry marks this OAuth provider as deprecated. Its risk notice says the subscription/OAuth session is not officially licensed for router use and the account may be restricted or banned. This is 9Router’s warning, not a promise of supported access. If that risk is unacceptable, use the official Antigravity app or the documented CLI API-key mode below instead.

You need a running 9Router instance, your own eligible account and a router API key. Review the provider’s permitted usage and the router’s Risk Notice before connecting. A third-party account connection does not expand model entitlement or demonstrate Google’s approval of the integration. These instructions are based on the current source, reviewed October 23, 2026; no account login or live model test was performed by this Wiki.

Connect the provider in 9Router

1. Open Providers, select Antigravity, and click Add Connection.
2. If Risk Notice appears, read the release-specific notice. Choose Cancel if its conditions are unsuitable. I Understand, Continue advances to login only if you accept them.
3. In Connect Antigravity, open the authorization URL shown in the modal and sign in with the intended account. Check the actual sign-in domain before entering credentials.
4. Allow the normal callback to complete. If the modal offers Step 2: Paste callback URL here, paste the callback into that local modal and click Connect. Do not put the callback in a public issue or chat: it can contain authorization data.
5. Wait for Connected Successfully!, close the modal, and verify the new connection is listed. If the modal reports Connection Failed, retain its redacted error and retry only after resolving it; the account is not connected merely because a browser opened.

The provider page and OAuth modal are the source for these labels. An older release can present another flow; update your instructions against that installed release instead of pasting tokens into an unrelated API-key form.

Discover and test one model

Use curl and jq in Bash/zsh. Set NINEROUTER_API_KEY locally to the router-issued key. List the available model identifiers:

curl --fail-with-body --noproxy '*' http://localhost:20128/v1/models \
  -H "Authorization: Bearer $NINEROUTER_API_KEY"

Choose an explicit model from the Antigravity provider’s dashboard/model list and set ROUTER_MODEL to that exact router-facing ID. Avoid a combo for this first check. A general model catalog can contain routes your account cannot use, so the following request is a separate access test and may consume account quota:

jq -n --arg model "$ROUTER_MODEL" \
  '{model:$model,messages:[{role:"user",content:"Answer with a short greeting."}],stream:false}' \
  > /tmp/antigravity-router-probe.json
curl --fail-with-body --noproxy '*' -i \
  http://localhost:20128/v1/chat/completions \
  -H "Authorization: Bearer $NINEROUTER_API_KEY" \
  -H 'Content-Type: application/json' \
  --data-binary @/tmp/antigravity-router-probe.json

A complete response with choices, plus a matching Antigravity connection in the router request log, establishes this text route. A successful OAuth callback establishes only the login step. Next, configure a supported coding client and test one harmless tool operation before using a real repository.

Diagnose and undo the connection

Failure	Action
Login succeeds but no connection appears	Return to the modal; complete its callback/manual Connect step and inspect the error
Local 401	Correct the router key; do not paste account OAuth data into the client
Upstream authorization or eligibility error	Check that account’s access and the installed provider notice; another local model alias cannot grant entitlement
Model unavailable or quota exhausted	Consult the account/product’s current availability; choose an actually entitled model or wait for its stated quota reset
Text works, tool request fails	Inspect the tool schema and translation in the installed release; preserve a minimal redacted reproduction

To stop using this route, restore your client’s saved base URL, key and model. Remove the dedicated account connection from the router only after checking that other clients do not depend on it; revoke the connected app authorization in the account’s own controls if you want to withdraw upstream access too. Deleting a local client setting is not the same as revoking account authorization.

If you meant Antigravity CLI, SDK or IDE instead

Product/direction	Documented entry point	Boundary
Antigravity CLI using a Gemini key	Merge "modelProvider":"gemini" into ~/.gemini/antigravity-cli/settings.json, set GEMINI_API_KEY, then start agy	This is Gemini API mode, not this provider login recipe
CLI using a custom Gemini endpoint	GOOGLE_GEMINI_BASE_URL in Google’s CLI documentation	An OpenAI chat URL is not automatically a Gemini-compatible URL
Python SDK using a local model server	Google’s LocalOpenAIAgentConfig documentation	SDK code, not an IDE setting; check authentication support separately
IDE interception/bridge	Version-specific upstream bridge instructions	A separate change involving proxy/trust behavior; this guide does not install it

For CLI recovery, preserve the other settings, remove only the temporary modelProvider override, restore prior environment values (or unset temporary GEMINI_API_KEY and GOOGLE_GEMINI_BASE_URL), and restart agy. Removing the key while leaving Gemini mode selected can leave the CLI unable to authenticate. Use Google’s CLI guide for that path and the SDK guide for SDK configuration.