I want to document a particularly difficult first-time setup experience with the Gemini API Managed Antigravity Agent, because I believe several independent problems currently combine into an unnecessarily fragile workflow.
Environment / project
Date: September 28, 2026
Google AI Studio project:
Default Gemini Project
Project ID:
gen-lang-client-01006797..
Billing:
Paid Tier 1 / prepaid
Agent:
antigravity-preview-09-2026
Api-Revision:
2026-05-20
Use case
The intended task was very simple:
Take an existing small macOS/Swift project, make it available to a Managed Antigravity Agent, and let the agent implement one small visual feature.
This eventually required roughly four hours of setup and troubleshooting.
The issue is not that an API requires technical configuration. The problem is that there does not appear to be one clear, reproducible end-to-end path for:
existing private project
→ remote environment
→ authentication
→ managed agent
→ edited project
Instead, several authentication and resource models appear to overlap or behave inconsistently.
- OAuth / ADC path
I installed the Google Cloud SDK and configured Application Default Credentials.
This eventually required:
- creating/configuring a Google Auth Platform application
- creating a Desktop OAuth client
- configuring myself as a test user
- authenticating ADC with the required scopes
- setting the quota project
- enabling Service Usage API
- enabling Cloud Resource Manager API
After this, the quota project was successfully attached to ADC.
- Managed Environment via OAuth
Using OAuth/ADC, creation of a Managed Environment succeeded.
Environment ID:
1edaaf54ccce1374b35471d2ff66c418
A local project was converted to tar.gz, uploaded and extracted into the environment.
A subsequent file listing confirmed that the project existed inside the environment under:
/workspace/KlausSaver_EDDIE_AGY
So OAuth/ADC authentication, environment creation and filesystem access were working.
- Antigravity background interactions become stuck
Multiple Antigravity interactions were created using:
agent:
antigravity-preview-09-2026
Api-Revision:
2026-05-20
environment:
1edaaf54ccce1374b35471d2ff66c418
agent_config:
{
“type”: “antigravity”,
“max_total_tokens”: 100000
}
background:
true
The API accepted the requests and returned valid interaction IDs with:
“status”: “in_progress”
However, subsequent GET requests showed no progress.
Example interaction:
v1_Chd6Y3E2YXVDYURPQ1MzYm9QaXFEaDBBbxIXemNxNmF1Q2FET0NTM2JvUGlxRGgwQW8
The returned resource remained:
status: in_progress
created:
2026-09-28T20:15:12.871123+00:00
updated:
2026-09-28T20:15:12.871123+00:00
There was no output and no observable progress.
In other words:
created == updated
even after waiting and polling.
This happened with more than one interaction.
- Cancellation behavior is unclear / non-functional
Attempts were made to cancel a stuck interaction.
Using:
POST …/INTERACTION_ID:cancel
returned:
404
Method not found.
Using:
POST …/INTERACTION_ID/cancel
returned:
{
“error”: {
“message”: “There was a problem processing your request. You will not be charged.”,
“code”: “invalid_request”
}
}
This leaves an important operational problem:
If a paid agent remains indefinitely in “in_progress”, how is the user supposed to reliably terminate server-side execution and prevent further token consumption?
- Synchronous execution was also problematic
A synchronous Antigravity request was subsequently attempted using the same environment and agent configuration, without background:true.
The HTTP connection remained open without producing observable output.
This made it impossible to distinguish between:
- productive server-side agent execution
- provisioning delay
- deadlock
- internal agent failure
- networking/socket waiting
- continued billable inference
For a paid agent API, this state is extremely uncomfortable because there is no visible progress or resource-consumption feedback.
- AQ API key behaves differently across Gemini endpoints
The AI Studio API key was then tested independently.
The following worked correctly:
GET /v1beta/models
x-goog-api-key: $GEMINI_API_KEY
The request returned the model list successfully.
So the API key itself was valid.
However, using the same API key with the Environment API resulted in:
403 PERMISSION_DENIED
“Method doesn’t allow unregistered callers (callers without established identity). Please use API Key or other form of API consumer identity to call this API.”
This happened both when attempting to read the existing environment and when attempting to create a new environment.
Therefore:
Gemini API + AQ key → works
Environment API + same AQ key → rejected as unregistered caller
The documentation needs to make the identity requirements for Managed Environments versus normal Gemini API endpoints much clearer.
- Private repository path adds another credential layer
As an alternative to uploading the project manually, I created a private GitHub repository containing the source project.
A fine-grained GitHub PAT was created with access only to that repository and read-only Contents permission.
The token was independently verified against the GitHub API:
GET /repos/prechtbritta-commits/KlausSaver
Result:
HTTP 200
So GitHub authentication was confirmed working.
This then required another credential configuration layer on the Gemini/Agent side in order to make a private repository available as a source for a new remote environment.
- Billing visibility makes troubleshooting much worse
During this troubleshooting, the AI Studio billing UI temporarily showed apparently contradictory values.
At one point the prepaid balance appeared negative, while later the same account showed:
Initial prepaid credit: €5.00
Remaining balance: €4.34
The billing UI itself warns that cost information may take hours, or potentially more than 24 hours, to settle.
This is particularly problematic for agentic workloads.
If an interaction is stuck at “in_progress”, the user needs to know in near real time:
- whether inference is actually running
- whether tokens are currently being consumed
- current token usage
- current cost
- remaining configured token budget
- whether cancellation actually stopped server-side execution
Without this information, troubleshooting a paid agent effectively becomes financial guesswork.
- Documentation problem
Individual pieces of the documentation are useful, but the complete real-world workflow is fragmented across multiple concepts:
- Gemini API keys
- AQ keys
- OAuth
- ADC
- quota projects
- Service Usage API
- Cloud Resource Manager API
- Managed Environments
- file upload/extraction
- Agent Credentials
- private Git sources
- remote environments
- Interactions API
- background execution
- polling
- cancellation
- billing/token limits
The obvious use case:
“I have an existing private code project and want a Managed Antigravity Agent to modify it”
should have one canonical end-to-end quickstart.
Currently, assembling that workflow requires navigating several separate documentation areas and discovering authentication boundaries through trial and error.
What I would like Google to clarify
-
What is the officially recommended authentication mechanism for antigravity-preview-09-2026 with Managed Environments?
-
Should AQ API keys work with /v1beta/environments?
If yes, why would a valid key that successfully calls /v1beta/models receive “unregistered callers” from the Environment API?
-
Is OAuth/ADC officially supported for Antigravity Interactions?
-
Is there a known issue with background:true and antigravity-preview-09-2026 where interactions remain indefinitely in_progress with created == updated?
-
What is the currently supported cancellation endpoint for these interactions?
-
How can a user verify that an in_progress agent is actually executing rather than stuck before significant token usage occurs?
-
Is there a supported way to obtain live token/cost consumption for an active interaction?
-
What is Google’s canonical workflow for:
private GitHub repository
→ authenticated source
→ remote environment
→ Antigravity agent
→ modified repository/files?
- Can Google provide one complete REST example for that workflow, including the correct authentication model?
Suggested product improvements
From this experience, I strongly recommend:
- one canonical end-to-end quickstart for existing private repositories
- one clearly documented authentication model for Managed Agents
- automatic prerequisite/API activation
- explicit provisioning/executing/tool-running states instead of generic in_progress
- reliable cancellation
- live token usage and cost visibility per interaction
- a hard monetary budget option in addition to max_total_tokens
- clearer error messages when authentication is valid for Gemini but not for Environment resources
- a setup wizard for remote environments and private repositories
The underlying agent technology may be powerful, but the current setup experience turns a very small coding task into a multi-hour infrastructure exercise.
I would particularly appreciate clarification from the Managed Agents / Antigravity team on the authentication boundary between Gemini API keys, Managed Environments and the Interactions API, and on the apparently stuck background interactions described above.